<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hallo zusammen,</p>
<p>Problem gelöst durch "alles neu" - "intermediate" war im
Binärformat.<br>
</p>
<p>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.</p>
<p>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,</p>
<p>Und "openssl verify" hat sich in meinen Augen nicht
prädestiniert, um Zertifikate lokal zu testen. <br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Am 01.08.24 um 18:32 schrieb Markus
Weber:<br>
</div>
<blockquote type="cite"
cite="mid:8e844fb6-865f-47e1-99ed-d76585591a24@markusweber.de">
also der Webserver welcher <span style="font-family:monospace">gehetzt-1.goe-con.de
ausliefert hat definitiv kein Zertifikat von Let's Encrypt.<br>
Das Zertifikat ist von "</span><span class="info">Goebel Consult
Certificate Authority" zertifiziert.</span></blockquote>
<p>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.<br>
</p>
<p>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 :-)<br>
</p>
<p>Letztendlich war Dein Hinweis der, weshalb ich das Problem gelöst
habe.<br>
</p>
<p></p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 01.08.24 um 18:29 schrieb Erwin
Hoffmann:</div>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Das ist schlicht falsch. Du kannst und darfst den dhparam File nicht an
das Cert konkatinieren. </pre>
</blockquote>
</p>
<p>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.)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:044d008ec37d28dcaa7a509ae55741f3d7eb11a6.camel@fehcom.de">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>
<blockquote type="cite">
</blockquote>
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?</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 01.08.24 um 18:22 schrieb Frank
Doepper:<br>
</div>
<blockquote type="cite"
cite="mid:2de9b458-143d-7b60-0fd4-de3f525ff7c9@taz.de">dhparam hab
ich noch nie in Server-Zertifikate inkludiert. <br>
</blockquote>
<p>Siehe oben: macht debops so. Allerdings wird diese Datei dann als
"chain.pem" angeboten:</p>
<p><span style="font-family:monospace"><span
style="color:#000000;background-color:#ffffff;"># ls -l
public/chain.pem </span><br>
… public/chain.pem -> cert_intermediate_dhparam.pem<br>
<br>
</span></p>
<br>
<p></p>
<div class="moz-signature">-- <br>
<span style="color:black">
Schönen Gruß <br>
Hartmut Goebel <br>
</span>
<span style="font-size:smaller">Dipl.-Informatiker (univ), CISSP,
CSSLP, ISO 27001 Lead Implementer</span><br>
<span style="font-size:smaller">Information Security Management,
Security Governance, Secure Software Development</span>
<p style="color:black" lang="de">
Goebel Consult, Landshut <br>
<a style="color:black" href="http://www.goebel-consult.de"
class="moz-txt-link-freetext">http://www.goebel-consult.de</a>
</p>
<p style="color:grey;font-size:smaller">
Blog:
<a style="color:grey !important;text-decoration:none !important"
href="https://www.goebel-consult.de/blog/2019/blockchain-bringts-nicht/"
class="moz-txt-link-freetext">https://www.goebel-consult.de/blog/2019/blockchain-bringts-nicht/</a>
<br>
Kolumne:
<a style="color:grey !important;text-decoration:none !important"
href="https://www.goebel-consult.de/blog/cissp-gefluester/2011-08-horrorszenario-bring-your-own-device/"
class="moz-txt-link-freetext">https://www.goebel-consult.de/blog/cissp-gefluester/2011-08-horrorszenario-bring-your-own-device/</a>
</p>
</div>
</body>
</html>