Leidiges Thema Nginx und SSL nach DynDNS wechsel

@KlaJo, meine Intention war es weder dich vom NPM weg zu locken, noch dir eine pfsense aufzuschwatzen. Meine Intention war es stattdessen mal zu testen, ob man grundsätzlich per ACME und Let’s Encrypt sowie einer DNS-Challenge für eine ipv64-Domain Zertifikate erzeugen kann.

Der Anlass dafür das zu testen war die von dir benannte Fehlermeldung „Interner Fehler“. So allgemein wie dieser Fehler klingt so deutlich lässt er dennoch vermuten, dass du intern auf dem NPM etwas nicht korrekt konfiguriert hast, oder der NPM das einfach nicht kann.

Da mich selbst nun aber der Ehrgeiz und die Neugier gepackt hat, hab ich dann die gestern testweise erzeugten Zertifikate gleich noch um Wildcard-Zertifikate auf der pfsense ergänzt. Denn das gestern erzeugte Zertifikat galt nur für XXXXX.ipv64.de und nun für *.XXXXX.ipv64.de

Die Option auch Wildcard-Zertifikate erzeugen zu können, die dann eben auch für beliebige Subdomains gelten, ist ja einer der Vorteile der Nutzung einer DNS-Challenge.

Das wird dir aber natürlich nicht weiterhelfen, wenn dein NPM an dieser Aufgabe, bei Nutzung von ipv64-Domains, scheitert.

Oh und dann habe ich gerade das hier entdeckt: ACME Let’s Encrypt mit Proxmox VE – DNS Challenge – HOWTO

Also wenn es mit dem NPM nicht klappt, warum lässt du den Job nicht einfach von deinem Proxmox erledigen?

PS: der Nginx Proxymanager soll das aber (auf entsprechende Nachfrage des Users René) laut Aussage von Dennis vom 19. Januar 2025 um 08:11 Uhr auch können.

1 Like

Hallo @The_eagle

Ich muss schon eingestehen alle Deine Erklärungen für mich nicht so einfach zu verstehen sind. Es ist schon Super mit welcher Ausdauer ihr den “nicht Wissenden helft”. Das HOWTO werde ich mir anschauen.

Was ich gestern noch probiert habe bei meinem Nginx Proxy Manager ist.

  • ich habe eine abc.ipv64.de Domain erstellt
  • Im Nginx habe ich einen Host mit abc.ipv64.de erstellt.
  • dann DNSMulti eingetragen
    dns_multi_provider = ipv64
    IPV65_API_KEY = meinKey

Dann habe ich ein Zertifikat bekommen.

Wenn ich aber zwischen den = Zeichen kein blank eingetragen hatte kommt der Fehler.

1 Like

Funktioniert auch mit NPM, als Domain *.XXXXXX.ipv64.de eintragen und DNS-Challenge mittels DNSmulti (bis vllt. irgendwann mal IPv64 integriert ist) - zumindest mache ich es bei mir so.

Die Variante direkt über Proxmox werde ich mir auch mal anschauen. Da muss ich das Zertifikat aber wahrscheinlich manuell in dem Reverse Proxy hinterlegen?

Dann scheint das des Rätsels Lösung zu sein :slight_smile: :+1:

Nachtrag: soeben bei mir mal ohne Leerzeichen getestet (dns_multi_provider=ipv64) und hat ebenfalls funktioniert…

Nachtrag 2:

Ich hoffe die 65 statt der 64 ist nur hier ein Tippfehler, sonst könnte das ein Hinweis auf den Ursprung des internal error sein…

so wie unter Nginx Proxy Manager + DNSChallenge + IPV64 Beschrieben hat es hier immer geklappt
ohne klammern, Leerzeichen ersichtlich. Link auch nur der Vollständigkeit halber. NPM 3 sollte IPV64 zur Auswahl haben nativ laut Dennis. dieser Lässt aber weiter auf sich warten. Man kann alternativ ggf auch Zoraxy versuchen.Dort ist IPV64 als Provider hinterlegt.

Wenn ich mich mal da einmische.

Ich habe das selber mit jeder Version von NPM das DNSMulti nicht mehr funktioniert

Dies ist das Dockerfile

FROM jc21/nginx-proxy-manager:latest
RUN apt-get update \
        && apt-get install -y --no-install-recommends wget curl python3-dev \
        && apt-get clean \
        && rm -rf /var/lib/apt/lists/*
RUN wget https://go.dev/dl/go1.26.3.linux-arm64.tar.gz
RUN tar -xzf go1.26.3.linux-arm64.tar.gz -C /usr/local && rm -f go1.26.3.linux-arm64.tar.gz
ENV PATH="/usr/local/go/bin:${PATH}"

Dies die entsprechende dockercompose

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    hostname: proxy
    healthcheck:
      test: ["CMD", "/bin/check-health"]
      interval: 10s
      timeout: 3s
    ports:
      # These ports are in format <host-port>:<container-port>
      - '80:80' # Public HTTP Port
      - '443:443/tcp' # Public HTTPS Port
    environment:
      DISABLE_IPV6: 'false'
    networks:
        proxy:

    volumes:
      - /opt/containers/nginx/data:/data
      - /opt/containers/nginx/letsencrypt:/etc/letsencrypt
      - /etc/timezone:/etc/timezone:ro
      - /usr/share/zoneinfo:/usr/share/zoneinfo:ro
    labels:
       - "diun.enable=false"
networks:
  proxy:

Diesen Code muss ich immer wieder nutzen mit jeder neuen Version weil in der NPM Version schlichtweg go fehlt um dnsmulti zu installieren, wenn dies gemacht wurde funktioniert dnsmulti ohne Probleme

Ja ist ein Tippfehler

1 Like

Hallo @markusonwheels

Genau das war mein Fehler.
Ja, ich werde mal Zoraxy probieren.

Interessant… Ich habs mittels Portainer aufgesetzt und noch nie etwas Richtung go machen müssen. Updates über Watchtower laufen auch problemlos und DNSmulti funktioniert einfach :person_shrugging:

Das ist seltsam, aber da ich kein Portainer nutze :slight_smile: kann ich da nicht mit reden.
ich habe alle meine compose files lokal und nutze eher die Befehle
aber egal mit welcher version ich habe nie DNS Multi zum laufen bekommen erst als ich selber go in das Images installiert hatte