https://<IP>/cmk/ endete im Browser mit ERR_SSL_UNRECOGNIZED_NAME_ALERT,
waehrend dieselbe Adresse ueber http funktionierte. Die Ursache liegt
nicht beim Zertifikat: RFC 6066 laesst in der SNI-Erweiterung keine
IP-Adressen zu, der Browser schickt bei einer IP also gar keinen Namen.
nginx kann den Server-Block dann nicht ueber den Namen waehlen und
faellt auf den Standard-Server zurueck - bei NPM ist das der Block aus
/etc/nginx/conf.d/default.conf mit "ssl_reject_handshake on". Ueber HTTP
faellt das nicht auf, dort entscheidet der Host-Kopf, und der traegt die
IP.
Nachgeprueft am Image jc21/nginx-proxy-manager:2 (2.15.1): der Block
steht dort in Zeile 36, und nginx.conf liest conf.d/*.conf vor den
Proxy-Hosts ein - damit wird er zum Standard-Server, obwohl keiner der
Bloecke "default_server" gesetzt hat. Mit einem eigenen Block, der das
Kennzeichen ausdruecklich traegt, ist der Fall entschieden; Aufrufe mit
Namen gehen unveraendert an ihren Proxy-Host.
Neu ist "proxy default":
proxy default Stand anzeigen
proxy default --domain X Proxy-Host X spiegeln
proxy default --off Spiegelung entfernen
--restart Proxy Manager gleich neu starten
Gespiegelt wird ueber die API: Ziel, Zertifikat und die zusaetzlichen
Pfade des Proxy-Hosts landen in einem Standard-Server-Block in der
Zusatzkonfiguration. Fuehrt das Zertifikat die IP nicht als
Alternativnamen, sagt der Befehl das vorher - bei Lets Encrypt geht es
prinzipbedingt nicht.
Dabei aufgefallen: die Zusatzkonfiguration liegt im Datenverzeichnis des
Proxy Managers und gehoert dem Container. Ohne Schreibrecht scheiterte
bisher nur ein nacktes "touch" - jetzt sagt npm_conf_writable, woran es
liegt, und nennt den sudo-Aufruf. Das gilt auch fuer "npm-port".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5
8782c6d5c7