[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