Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 23 replies
  • Answers 3 answers
  • Subscribers 7 subscribers
  • Views 9197 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WAF + Let's Encypt

Michael Henkes

Hallo, selbst nachdem ich das alte R3 entfernt habe, das X3 automatisch gelöscht und die UTM neugestartet habe, gibt die UTM WAF (reverse proxy) immer noch den alten Pfad mit aus.

www.ssllabs.com:

Certification Paths
Path #1: Trusted
1 Sent by server xxx.domain.com
Fingerprint SHA256: c6fd72b49484c6124acd17f5bff8d90bf941200e889d67a607511f72ac429dfd
Pin SHA256: thxSHxnuQfCLGcjZzukPDVgDsYMm8Dc7L6KvNWLdB2I=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server R3
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store ISRG Root X1   Self-signed
Fingerprint SHA256: 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
Path #2: Not trusted (invalid certificate [Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739])
1 Sent by server xxx.domain.com
Fingerprint SHA256: c6fd72b49484c6124acd17f5bff8d90bf941200e889d67a607511f72ac429dfd
Pin SHA256: thxSHxnuQfCLGcjZzukPDVgDsYMm8Dc7L6KvNWLdB2I=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server R3
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
RSA 2048 bits (e 65537) / SHA256withRSA
3 Sent by server ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
4 In trust store DST Root CA X3   Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
EXPIRED
Weak or insecure signature, but no impact on root certificate

Lösche ich das aktuelle R3 aus der UTM, wird der Pfad nicht mehr mit ausgegeben aber verschieden Endgeräte können keine vertrauenvolle Verbindung mehr aufbauen.

Hat dazu jemand eine Lösung ohne die Endgeräte einstellen zu müssen?



This thread was automatically locked due to age.
Parents
  • +1

    Habe die Lösung gefunden

    Es gibt 2 verschiedene X1 Zertifikate:

    Korrekt
    Fingerprint: CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8

    Veraltet
    Fingerprint: 93:3C:6D:DE:E9:5C:9C:41:A4:0F:9F:50:49:3D:82:BE:03:AD:87:BF

    Download korrektes X1: https://letsencrypt.org/certs/isrgrootx1.pem

    Löscht man das alte X1 (welches automatisch installiert wird bei LetsEncrypt Zertifikaten) und läd das korrekte hoch, sendet die WAF nur noch den gültigen Pfad

    Die Zertifikate muss man nicht neu ausstellen.

    Wäre super wenn das in Zukunft automatisch passiert @SOPHOS

  • 0 in reply to Michael Henkes

    Erneuert man das Zertifikat manuell (oder wohl auch automatisch) wird das falsche X1 wieder nachgeladen.

    Laut Tests via ssllabs.com wird der Pfad aber nicht mitgegeben

  • 0 in reply to Michael Henkes

    Problem liegt daran das bei der Erstellung von Zertifikaten eine Option PREFERRED_CHAIN="ISRG Root X1" fehlt.
    Noch dazu kann man diese Option nur in aktuelle dehydrated Version 0.7.0 nutzen.. derzeit ist v0.6.5 in Verwendung Disappointed
    ..und es geht nur mit Zertifikat Erzeugung, also auch mit diese Option, geht renew leider nicht.

    Info:
    github.com/.../releases

    ..wir können nur hoffen das SOPHOS dehydrated auf v0.7.0 so schnell wie möglich updatet, sonst wird es echt mühsam, nämlich nach jede Zertifikat Verlängerung muss man die falsche CA wieder löschen Disappointed ...bei mir hab ich jetzt das auto-renew deaktiviert, ich brauche keine Überraschungen mitten im betrieb.

  • 0 in reply to Zeljko Lajic

    BITTE SOPHOS FIXT DAS

    Hatte heute den Fall, dass plötzlich wieder das falsche X1 gesendet wurde und die Clientverbindungen so nicht mehr zu Stande gekommen sind

  • 0 in reply to Michael Henkes

    Das Zertifikat wurde auch schon mal erneuert?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Reply Children
  • 0 in reply to dirkkotte

    Bei einem manuellen renew wird zwar das falsche X1 nachgeladen, aber nicht direkt an den client gesendet.

    Keine Ahnung ab wann und wieso plötzlich wieder das flasche gesendet wird.

  • 0 in reply to Michael Henkes

    Bei mir wird immer die falsche X1(gültig bis 2024) sofort nach renew nachgeladen und gleich benutzt. Ich teste es immer mit openssl von meine linux box.

    Richtig:
    $ openssl s_client -connect valid-isrgrootx1.letsencrypt.org:https | head

    depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
    verify return:1
    depth=1 C = US, O = Let's Encrypt, CN = R3
    verify return:1
    depth=0 CN = valid-isrgrootx1.letsencrypt.org
    verify return:1
    CONNECTED(00000005)
    ---
    Certificate chain
     0 s:CN = valid-isrgrootx1.letsencrypt.org
       i:C = US, O = Let's Encrypt, CN = R3
     1 s:C = US, O = Let's Encrypt, CN = R3
       i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
    ---

    Falsch:
    $ openssl s_client -connect letsencrypt.org:https | head

    depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
    verify return:1
    depth=1 C = US, O = Let's Encrypt, CN = R3
    verify return:1
    depth=0 CN = lencr.org
    verify return:1
    CONNECTED(00000005)
    ---
    Certificate chain
     0 s:CN = lencr.org
       i:C = US, O = Let's Encrypt, CN = R3
     1 s:C = US, O = Let's Encrypt, CN = R3
       i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
     2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
       i:O = Digital Signature Trust Co., CN = DST Root CA X3
    ---

    Meine "workaround" ist derzeit bei alle Zertifikate eine manuelle renew zu machen, und auto renew dann deaktivieren.. und das ganze dann nach ca. 2,5 Monate wiederholen.

    Auf ssh shell wird mit eine leere Datei das auto renew script deaktivieren.

    touch /tmp/disable_letsencrypt_renew_certificates
    oder
    echo > tmp/disable_letsencrypt_renew_certificates

Unfiltered HTML