Eine Odyssee. Tierisch und nervig.

Am 27.08. waren die guten, alten Let’s Encrypt-Zertifikate für meine Subdomains fällig. Gesagt, getan, den alten CertBot (das originale…total performante Ding von LE) angeworfen und versucht die in Bälde auslaufenden Zertifikate zu aktualisieren. Konnte es denn so einfach sein?

 

Es konnte nicht.

 

Zwei der drei eingereichten Zertifikate waren nicht fällig und wurden übersprungen. Soweit so gut. Beim Dritten passierte einfach gar nichts. Nichts. Nada. Keine Fehlermeldung, kein gar nichts. Nur durch einen beherzten Griff auf Strg+C konnte das laufende Programm abgebrochen werden und zeigte mir ominöse Fehlermeldungen im dahinter liegenden Code, die bis auf ein augenscheinliches SSL-Problem nicht hilfreich waren. Großes Tennis. Selbst im Log, welches der Bot anlegte, war nichts. Ich löschte also den LE-Ordner im Verzeichnisbaum, weil ich davon ausging, dass das Ding die letzten Updates nicht verkraftet hatte.

Erst da fiel mir auf, dass es den „alten“ Bot schon gar nicht mehr gab, richtete CertBot ein und versuchte erneut mein Glück.

Ich wurde enttäuscht. Die gleiche Fehlermeldung, keine Antworten im Log. Nur die Tatsache, dass die Zertifikate fällig wurden und er versuchte mit dem ACME von LE Kontakt aufzunehmen.

Lange Rede, kurzer Sinn: IPv6. Nach einem Dist-Upgrade hat sich anscheinend meine Anpassung der sysctl.conf verflüchtigt.

Darauf gekommen bin ich recht umständlich. Ich benutzte curl:

root@host:/opt/certbot# sudo curl -v https://acme-v01.api.letsencrypt.org/directory
* Hostname was NOT found in DNS cache
* Trying 2a02:26f0:10:28d::3d5...
* Connected to acme-v01.api.letsencrypt.org (2a02:26f0:10:28d::3d5) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to acme-v01.api.letsencrypt.org:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to acme-v01.api.letsencrypt.org:443

Da sieht man auch wieder den ominösen SSL-Error, der mich stutzig machte. Das weiter zu verfolgen erwies sich aber als Sackgasse. Das normale curl benutzt anscheinend ohne Flag die IPv6-Einstellung. Wie man an dem * Trying 2a02:26f0:10:28d::3d5... sehen kann. Soweit so gut. Irgendwann überkam mich also die Einsicht mal zu testen, ob es mit einem IPv4-Flag funktioniert.

sudo curl -v -4 https://acme-v01.api.letsencrypt.org/directory

* Hostname was NOT found in DNS cache
*   Trying 23.0.33.82...
* Connected to acme-v01.api.letsencrypt.org (23.0.33.82) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: CN=*.api.letsencrypt.org; O=INTERNET SECURITY RESEARCH GROUP;                                    L=Mountain View; ST=California; C=US
*        start date: 2015-06-26 17:05:45 GMT
*        expire date: 2018-06-25 17:05:45 GMT
*        subjectAltName: acme-v01.api.letsencrypt.org matched
*        issuer: C=US; O=IdenTrust; OU=TrustID Server; CN=TrustID Server CA A52
*        SSL certificate verify ok.
> GET /directory HTTP/1.1
> User-Agent: curl/7.35.0
> Host: acme-v01.api.letsencrypt.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server nginx is not blacklisted
< Server: nginx
< Content-Type: application/json
< Content-Length: 280
< Boulder-Request-Id: DtR_dWdAimq7NP4Kppw6beNPRu6vfNbplKb-o1_M2bs
< Replay-Nonce: HT8EzQuvnEcqfPJYTuDQJnDkt4hpewKj0ziD5kYcZLc
< X-Frame-Options: DENY
< Strict-Transport-Security: max-age=604800
< Expires: Tue, 19 Jul 2016 10:33:23 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Tue, 19 Jul 2016 10:33:23 GMT
< Connection: keep-alive
<
{
  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v01.api.letsencrypt.org left intact

Und ja; tuts. Mit einem explizit aufgerufenen curl -4 bekommt man einen 200er zurück. Perfekt. Was nun? Anscheinend funktioniert das IPv6 in LE immer noch nicht (zuverlässig)

Also mussten meine Anpassungen wieder in die /etc/sysctl.conf :

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Testen, ob nun wirklich IPv6 deaktiviert ist, kann man mit einem cat /proc/sys/net/ipv6/conf/all/disable_ipv6 welches dann hoffentlich eine 1 ausgibt. Danach lief auf CertBot wieder ohne Probleme durch.

Anscheinend soll mittlerweile das Problem mit dem IPv6-Stack gelöst worden sein.

Nachlesen kann man den Fall auf GitHub hier^[1]CertBot Issue #2615

Den Blogeintrag im DevBlog zur vollen Unterstützung von IPv6 findet ihr hier^[2]LE Full IPv6 Support

Tagged apache2, certbot, IPv6, lets encrypt, renew, zertifikate