SSL-Fehler bei ACME-Verlängerung

Ultrashadow · 14. Februar 2018

Hallo zusammen,

kurioserweise funktioniert derzeit bei mir die Verlängerung der Zertifikate nicht. Bei der Fehlersuche wurde getestet, ob es Probleme bei der Firewall gibt, da LiveConfig auch keine Updates mehr überprüft. Ein Problem hierbei konnte ich nicht finden.

Im Log zur Verlängerung findet sich

Code

[2018/02/07 23:13:02.217153] [1104|3599] SSL error: 5
[2018/02/07 23:13:02.217169] [1104|3599] HTTPClient: error at SSL handshake (state=3)
[2018/02/07 23:13:02.217215] [1104|3599] ACME/getNonce: connection failed (https://acme-v01.api.letsencrypt.org/directory)
[2018/02/07 23:13:02.217251] [1104|3599] ACME: can't create new authorization request for 'www.domain.tld':

Ich benutze LiveConfig in der Version 2.5.3 (r4805) die automatische Verlängerung scheint aber schon in der vorherigen Version nicht mehr funktioniert zu haben.

vielen Dank für eure Hilfe

kk · 14. Februar 2018

Ich vermute, dass es (aus welchem Grund auch immer) Verbindungprobleme zum CA-Server von Let's Encrypt gibt.
Wenn Sie "openssl" auf dem Server installiert haben, führen Sie bitte mal testweise folgenden Befehl aus:

Code

openssl s_client -connect acme-v01.api.letsencrypt.org:443

Kann damit eine TLS-Verbindung aufgebaut werden, oder gibt es eine Fehlermeldung?

Ultrashadow · 14. Februar 2018

Ja, eine Verbindung kann aufgebaut werden und der Handshake funktioniert, keine Fehlermeldung

Ultrashadow · 15. Februar 2018

Hier noch der Output von der openssl-Abfrage

Code

Verify return code: 0 (ok)

Und noch ein paar weitere Daten
PHP-Version 7.1.13
CentOS Linux release 7.4.1708
Apache/2.4.6

ACME-Verlängerung funktioniert davon unabhängig nicht

kk · 15. Februar 2018

Zitat von Ultrashadow

CentOS Linux release 7.4.1708

Ist zufällig SELinux aktiviert? (was liefert der Befehl "getenforce"?)
Wenn ja, dann könnte hier das Problem liegen (es gibt Regeln, welche Prozessen ausgehende TCP-Verbindungen verbieten...)

Ultrashadow · 15. Februar 2018

SELinux steht auf permissive...

Ultrashadow · 17. Februar 2018

Hallo,

leider sind unsere Zertifikate nun abgelaufen und es ist auch nicht möglich, einen weiteren Account anzulegen oder neue Zertifikate auszustellen. Externe Faktoren können wir ausschließen, da an der Serverkonfiguration seit der Installation des Servers keine Änderungen vorgenommen wurde und zu dem Zeitpunkt die Nutzung und Validierung von Let's Encrypt-Zertifikaten möglich war. Ich möchte das Problem deshalb gerne zügig lösen.

kk · 17. Februar 2018

Wir haben hier auf CentOS7 (und auch auf allen anderen Distributionen) nicht das geringste Problem mit Let's Encrypt.
Die Meldung "SSL Handshake Failed" deutet darauf hin, dass zwar die TCP-Verbindung selbst zum Let's-Encrypt-Server aufgebaut werden kann, danach aber ein Fehler beim SSL-Handshake auftritt.

Führen Sie den o.g. "openssl"-Befehl bitte noch mal als Benutzer "liveconfig" aus (also erst mit "su -s /bin/bash liveconfig" den Benutzer wechseln).

Ultrashadow · 18. Februar 2018

Auch das ist getestet und hier sind die Ergebnisse

Code

[user@host ~]# sudo su -s /bin/bash liveconfig
bash-4.2$ pwd
/var/lib/liveconfig
bash-4.2$ openssl s_client -connect acme-v01.api.letsencrypt.org:443
Verify return code: 0 (ok)

Tatsächlich hat LiveConfig in einigen Ordnern keine Execution-Rechte, im Home unter /var/lib/liveconfig sowie unter /srv/www/liveconfig aber schon. Für mich lässt sich hieraus kein Problem erschließen.

Könnte das Problem etwas mit PHP zutun haben? Neben Updates gab es unter anderem ein Versionsprung von 5.4 auf 7.1 (5.4 komplett entfernt)

kk · 18. Februar 2018

Zitat von Ultrashadow

Auch das ist getestet und hier sind die Ergebnisse

Code

[user@host ~]# sudo su -s /bin/bash liveconfig
bash-4.2$ pwd
/var/lib/liveconfig
bash-4.2$ openssl s_client -connect acme-v01.api.letsencrypt.org:443
Verify return code: 0 (ok)

Bei dem o.g. SSL-Befehl muss es erheblich mehr Output geben als nur "Verify return code: 0". Bitte schicken Sie uns mal die gesamte Ausgabe dazu, dazu noch die Ausgabe von "openssl version".

Zitat

Tatsächlich hat LiveConfig in einigen Ordnern keine Execution-Rechte, im Home unter /var/lib/liveconfig sowie unter /srv/www/liveconfig aber schon. Für mich lässt sich hieraus kein Problem erschließen.

Was meinen Sie mit "in einigen Ordnern"? Haben Sie einige Berechtigungen eingeschränkt?
Es kann z.B. durchaus ein Problem sein, wenn LiveConfig keinen Zugriff auf die CA-Zertifikate des Systems hat.

Zitat

Könnte das Problem etwas mit PHP zutun haben? Neben Updates gab es unter anderem ein Versionsprung von 5.4 auf 7.1 (5.4 komplett entfernt)

Was für ein Update war das denn? CentOS 7 bringt nur PHP 5.4 mit.
LiveConfig (und insbes. der integrierte ACME-Client) laufen unabhängig von PHP.

Ultrashadow · 18. Februar 2018

Zitat

Bei dem o.g. SSL-Befehl muss es erheblich mehr Output geben als nur "Verify return code: 0". Bitte schicken Sie uns mal die gesamte Ausgabe dazu, dazu noch die Ausgabe von "openssl version".

Ja, sicher gibt es mehr Output, ich habe es lediglich etwas gekürzt, zur Übersicht.

Code

openssl s_client -connect acme-v01.api.letsencrypt.org:443
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = IdenTrust, CN = IdenTrust Commercial Root CA 1
verify return:1
depth=1 C = US, O = IdenTrust, OU = TrustID Server, CN = TrustID Server CA A52
verify return:1
depth=0 CN = *.api.letsencrypt.org, O = INTERNET SECURITY RESEARCH GROUP, L = Mountain View, ST = California, C = US
verify return:1
---
Certificate chain
 0 s:/CN=*.api.letsencrypt.org/O=INTERNET SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
   i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
 1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
   i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
 2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHDzCCBfegAwIBAgIQfwAAAQAAAU4w1QtkQskueDANBgkqhkiG9w0BAQsFADBa
MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQLEw5UcnVz
dElEIFNlcnZlcjEeMBwGA1UEAxMVVHJ1c3RJRCBTZXJ2ZXIgQ0EgQTUyMB4XDTE1
MDYyNjE3MDU0NVoXDTE4MDYyNTE3MDU0NVowgYUxHjAcBgNVBAMTFSouYXBpLmxl
dHNlbmNyeXB0Lm9yZzEpMCcGA1UEChMgSU5URVJORVQgU0VDVVJJVFkgUkVTRUFS
Q0ggR1JPVVAxFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxEzARBgNVBAgTCkNhbGlm
b3JuaWExCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAlkLBpvVuOTZrpaPkzmAx+5OcK6gffKPon8E6ktJmNsjfrh3ATdgKt121ccD+
7I3gBcZu5euG1ldynO/wx29oeGhBiiWx9Bkm1brFKDLvH56ztO29xEo5ZQnxV7w0
25NvjBca5J2tRiAIjcdjMITE1usp5rrNLNM2LIs1RutP7bexvuNv2dGyJ0uNIWI4
Ym2Tt5rnUTx7Vsz0M4nz2i6sSB9ajrSa1h4hFrZYqIU/zpl20f7So8oZDYCZN4WY
xYgbUuEneWxFigElkJbNk0UeVN26tdMGHdIWCabgoZSy80X+pFvxCgdbLQzS0LXQ
orqkGsMYO0+fjjmLj0742IHYswIDAQABo4IDozCCA58wDgYDVR0PAQH/BAQDAgWg
MIICJwYDVR0gBIICHjCCAhowggELBgpghkgBhvkvAAYDMIH8MEAGCCsGAQUFBwIB
FjRodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xp
Y3kvdHMvMIG3BggrBgEFBQcCAjCBqhqBp1RoaXMgVHJ1c3RJRCBTZXJ2ZXIgQ2Vy
dGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVu
VHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw
czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMv
MIIBBwYGZ4EMAQICMIH8MEAGCCsGAQUFBwIBFjRodHRwczovL3NlY3VyZS5pZGVu
dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvMIG3BggrBgEFBQcCAjCB
qhqBp1RoaXMgVHJ1c3RJRCBTZXJ2ZXIgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNz
dWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRp
ZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3Qu
Y29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvMB0GA1UdDgQWBBQvAQatcXq62MSt
v2WLHPKwErqzgDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5p
ZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhNTIuY3JsMIGEBggrBgEFBQcBAQR4
MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3AuaWRlbnRydXN0
LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv
bS9jZXJ0cy90cnVzdGlkY2FhNTIucDdjMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAfBgNVHSMEGDAWgBSiViQ80NQVuei/eKMTEFhILhZU4TA1BgNVHREE
LjAsghUqLmFwaS5sZXRzZW5jcnlwdC5vcmeCE2FwaS5sZXRzZW5jcnlwdC5vcmcw
DQYJKoZIhvcNAQELBQADggEBAIgV29HRYYk2RfrkE6KOeAT6K3AJsKgNe+i9Pdo7
YLdiDGMv/kKyyTNsq4l8IEaY1kw3aqkyT44D8vp6yGbbNl1uAE4VnaPeChLOBK0G
xz3CjtoZPqLxmieft8jybIVWZKZlIIsZrSMaEvrmRTGYartBSuxqOzIjCNxvkkRt
MYDNYRhiy6NPMtA0kpDQCN6tOggXdCm19kmzKI8pUvQGCnGscXJvlQIeaZva0GWf
UOuPael/zohUUsm2lJowlIli939RdxUal0hwv8tD12qAyZAF2/+4y61ds4svGD9B
ukNnsAzS3EXNqq5qWFqRQyiTZfCcjaXEdtySyNAUiM6eFTY=
-----END CERTIFICATE-----
subject=/CN=*.api.letsencrypt.org/O=INTERNET SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
issuer=/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5917 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: CFB479B8BC457D5DDF998905D568A0BF6BB518F0C1741F11D79C01FA6798F886
    Session-ID-ctx:
    Master-Key: 8CE444FE8528BE53CF6AB4CD86178E82ED59CE5E0B75CAE1F2F02EE081169445AEADF24FC46429A3176F2FF3E517673F
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 00 00 03 d5 ab 22 48 2d-e9 c3 ed 4b 7a e9 52 86   ....."H-...Kz.R.
    0010 - a0 42 ec d2 6c 26 f3 1f-fc 46 67 2c 41 61 8b af   .B..l&...Fg,Aa..
    0020 - 77 5c 43 5b 74 b7 60 83-af e2 45 d1 62 2f e2 bd   w\C[t.`...E.b/..
    0030 - 77 66 41 90 f3 08 a9 69-42 2e 9b 29 f6 c4 ea 3e   wfA....iB..)...>
    0040 - 92 c1 d4 e9 6c 9b 57 cd-b3 89 d6 d0 38 10 0b 31   ....l.W.....8..1
    0050 - 7b 86 cf 92 19 8f fb 93-7e e2 09 1a 81 b0 01 00   {.......~.......
    0060 - f2 7d 69 65 a2 fa f0 77-9d 56 e8 3a 40 ff 4e a3   .}ie...w.V.:@.N.
    0070 - 6a 9b dc d9 e7 82 8d 5f-84 a7 b0 c2 57 5d 42 94   j......_....W]B.
    0080 - e1 cb ba a3 53 b0 5d 52-bf e5 b0 ce 65 74 54 e6   ....S.]R....etT.
    0090 - f8 02 db 83 34 3e 19 c0-6a 9f 52 e0 ce e1 c5 93   ....4>..j.R.....


    Start Time: 1518971833
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
closed

Alles anzeigen

Code

OpenSSL 1.0.2k-fips  26 Jan 2017

Zitat

Es kann z.B. durchaus ein Problem sein, wenn LiveConfig keinen Zugriff auf die CA-Zertifikate des Systems hat.

LiveConfig hat keinen Zugriff auf Verzeichnisse die zu anderen Anwendungen und Usern gehören - so weit, so normal. Die genannten Verzeichnisse sind die, die wir für den Betrieb relevant hielten und die haben wir getestet. LiveConfig hat Zugriff auf die CA-Zertifikate.

Zitat

Was für ein Update war das denn? CentOS 7 bringt nur PHP 5.4 mit.

Richtig, die PHP-Version stammt aus den IUS-Repos.

Zitat

LiveConfig (und insbes. der integrierte ACME-Client) laufen unabhängig von PHP.

kk · 18. Februar 2018

Schicken Sie uns bitte eine kurze Mail an support@liveconfig.com - wir würden Ihnen dann morgen eine Debug-Version schicken, welche den SSL-Handshake detaillierter protokolliert.

SSL-Fehler bei ACME-Verlängerung

Jetzt mitmachen!

Tags