[sage] [DaLUG] SSL-Problem: unable to get local issuer certificate
Hartmut Goebel
h.goebel at goebel-consult.de
Sat Aug 3 16:41:43 CEST 2024
Hallo zusammen,
Problem gelöst durch "alles neu" - "intermediate" war im Binärformat.
Danke für sie Antworten, meine Antworten fasse ich unten in einer Mail
zusammen. Leider hat keiner der Hinweise wirklich geholfen. Ich habe
daraufhin die gesamte Zertifikatskette, incl Key und Requests weg
geschmissen und neu erstellt. (Ich nutze debops, daher ist das relativ
wenig Aufwand.) Nun wird überall das richtige Zertifikat ausgeliefert
und akzeptiert.
Woran es lag, kann ich nur raten. Allerdings ist mit aufgefallen, dass
"intermediate.pem" im Binärformat war und nicht Ascii-Armored. Das war
mir komisch vorgekommen, aber da "openssl verify" sich daran nicht
gestört hat, dachte ich, das wäre egal und habe es nicht weiterverfolgt,
Und "openssl verify" hat sich in meinen Augen nicht prädestiniert, um
Zertifikate lokal zu testen.
Am 01.08.24 um 18:32 schrieb Markus Weber:
> also der Webserver welcher gehetzt-1.goe-con.de ausliefert hat
> definitiv kein Zertifikat von Let's Encrypt.
> Das Zertifikat ist von "Goebel Consult Certificate Authority"
> zertifiziert.
Es gingt um das Zertifikat für XMPPS (Port 5270). Ich hatte nicht
gedacht, dass jmd. das direkt ausprobiert, darum habe ich den Port nicht
angegeben.
Der Webserver wird nur für ACME genutzt, daher wäre das nicht so
relevant gewesen. ABER: Der nginx hat hier ein anderes Zertifikat
ausgeliefert, als er sollte und als konfiguriert war. Frage mich nicht
weshalb. Ich habe über 1 Stunde gesucht und dann einfach alles
weggeworfen und neu gemacht :-)
Letztendlich war Dein Hinweis der, weshalb ich das Problem gelöst habe.
Am 01.08.24 um 18:29 schrieb Erwin Hoffmann:
> Das ist schlicht falsch. Du kannst und darfst den dhparam File nicht an
> das Cert konkatinieren.
Weshalb "darf" ich nicht? Ist das ein Sicherheitsrisiko? debops macht
das von selbst so. washalb mich sehr interessieren würde, wenn dem so
ist. (Funktionieren tut es. ging früher und jetzt auch wieder.)
> alles soweit ok, nur der dhparam file hat mit der X.509 Cert GAR NICHTS
> zu tun. Eigentlich gibt es auch kein DLog DH mehr:
>
> Evtl. unterstützt Deine Implementierung noch DLog DH, dann brauchst Du
> das File dafür. Alle Dateien kannst Du wunderbar mit dem vi anschauen.
> Dann siehst Du was Du bekommst.
Mit dieser Aussage kann ich leider gar nichts anfangen. "Discrete
logarithm Diffie-Hellman" habe ich herausgefunden. Aber welche
praktischen Auswirkungen auf meine Konfiguration hätte das? Und wie
bekäme ich heraus, ob meine Implementierung das unterstützt? Wenn es das
aber gar nicht mehr gibt, was nutzt es dann, wenn meine Implementierung
es noch nutzt?
Am 01.08.24 um 18:22 schrieb Frank Doepper:
> dhparam hab ich noch nie in Server-Zertifikate inkludiert.
Siehe oben: macht debops so. Allerdings wird diese Datei dann als
"chain.pem" angeboten:
# ls -l public/chain.pem
… public/chain.pem -> cert_intermediate_dhparam.pem
--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development
Goebel Consult, Landshut
http://www.goebel-consult.de
Blog: https://www.goebel-consult.de/blog/2019/blockchain-bringts-nicht/
Kolumne:
https://www.goebel-consult.de/blog/cissp-gefluester/2011-08-horrorszenario-bring-your-own-device/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.guug.de/pipermail/sage/attachments/20240803/6af8afac/attachment.html>
More information about the SAGE
mailing list