Die kuriose Let’s Encrypt Zertifikatsvernichtung

Ihr habt sicher von der Let’s Encrypt Aktion  gehört, bei der am Mittwoch 4 Millionen Zertifikate für ungültig erklärt werden sollten und nun tatsächlich nur noch 1.3 Millionen entwertet wurden.  Was Ihr nicht gehört habt ist der Umstand, daß die Zahlen komplett überzogen sind und die Begründung auch nicht für alle stimmt.

1.3 Millionen Zertifikate für ungültig erklärt.

Am 3.3. kam folgende Email bei uns an:

ACTION REQUIRED: Renew these Let’s Encrypt certificates by March 4

We recently discovered a bug in the Let’s Encrypt certificate authority code, described here:

https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid
disruption, you’ll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologize for the issue.

… Erklärung was man tun  muß …

Your affected certificate(s), listed by serial number and domain names:

03ecb7303d580891307fd3a47b380d312f4f: einedomain.de www.einedomain.de
030957775b69a991e4dd80c6d598aad621d1: eineanderedomain.de www.eineanderedomain.de
03454b86a0b34e3fced270c8cf31eff99e9c: einedomain.de www.einedomain.de
0380ffb6959d746e0dac1cc397d696e20997: eineanderedomain.de www.eineanderedomain.de
0444954637f2defb07cb113a612ec46b19a9: einedomain.de www.einedomain.de
03bb883d4c37e1a71afdff2d379ffcf3e023: eineanderedomain.de www.eineanderedomain.de
03143a5f2efaba0dc3083ac61b160cd0d9f6: einedomain.de www.einedomain.de
044967b81422a9cb42a24d4c3349a3809106: eineanderedomain.de www.eineanderedomain.de
03ea3701bebb2679bcb5dd9f49308a90ad6e: einedomain.de www.einedomain.de
034d72dd79494e8d34843c3e0dcd99dc0229: eineanderedomain.de www.eineanderedomain.de
032fd14c38423850ea037b09b4868c1d92ff: einedomain.de www.einedomain.de
03dd1bf96a9a77edcde65dd49dcb65c77619: eineanderedomain.de www.eineanderedomain.de
03e2c85073fcf4e4a807e4fe7674a4e8342e: eineanderedomain.de www.eineanderedomain.de
03c802547e5f9b20704cf3385f5d64e4cab4: einedomain.de www.einedomain.de
03a75558e1bef0c4a68d8d437758d0c36743: eineanderedomain.de www.eineanderedomain.de
049ce54f1a025d3581408b7e1f39c82bf761: einedomain.de www.einedomain.de
0389bef9a312c1cf568d9af54f7e20003a37: eineanderedomain.de www.eineanderedomain.de
04a7b495e56693c4847a259f68c1cb3dca0d: einedomain.de www.einedomain.de
03671ac363d115d81991fb78b4efa00b72b8: eineanderedomain.de www.eineanderedomain.de
04dda4b6e006f8fb5c17b8e98ec60cc5c487: einedomain.de www.einedomain.de
04f7293f6e2f18d11f0e7f4ac1b03f32ac66: eineanderedomain.de www.eineanderedomain.de
033f28ecf7cdfdf9094fef13e295a2fb6702: eineanderedomain.de www.eineanderedomain.de
035af3d7a2209dcd5a6eee2ebfb0b774ab9f: pma.{einedrittedomain.de} {einedrittedomain.de} webmail.{einedrittedomain.de} www.{einedrittedomain.de}

Wie man sehen kann, sind das Zerts für eine winzige Anzahl an Domainnamen, die ALLE SAMT schon vor Jahren ausgestellt wurden und schon lange ersetzt und ungültig sind. Ich habe keine Ahnung was Let’s Encrypt da genau gemacht hat, aber es ist defakto Blödsinn gewesen. Offensichtlich hat da niemand die Ablaufdaten geprüft, sonst wäre das nicht passiert. Ganz unbekannt ist das Problem bei Let’s Encrypt nicht:

Q: I received the email telling me I should renew my certificate, however, the online testing tool isn’t indicating my cert needs replacing.
A: Even if you received an email, it’s possible that the affected certificates have been replaced by newer certs not affected by the bug. (Either due to being issued in the last few days since it was fixed, or simply by not meeting the specific timing criteria necessary for the bug to trigger.) In that case, it’s not necessary to renew them again. You can use the checking tool at https://checkhost.unboundtest.com/ to verify if the certificate you’re currently using needs renewal, or verify that the serial number of the cert you’re currently using is present in the list of affected certs at https://letsencrypt.org/caaproblem/.

Da uns Certs teilweilse vom Start des Testbetriebs von LE angegeben wurden, kann man annehmen, daß die Uhren in Amiland anders ticken 🙂 Certs werden 20 Tage vor Ablauf automatisch erneuert, so daß man bei der Menge oben leicht ausrechnen kann, wie alt die sein müßten 😉

CAA & DNS

Kommen wir zu nächsten Ungereihmheit bei der Sache, der CAA Validierung. Wie man in dem Artikel „https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591“ nachlesen, daß die ganze Aktion ausgelöst wurde, bei bei CAA Einträgen falsch geprüft wurde. Dafür müßten aber folgende Bedingungen erfüllt sein:

CAA verwenden

Wenn Sie sich nicht für CAA interessieren, müssen Sie im Allgemeinen nichts tun (siehe jedoch unten die CAA-Fehler). Wenn Sie mithilfe von CAA einschränken möchten, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen, müssen Sie einen DNS-Anbieter verwenden, der die Einstellung von CAA-Einträgen unterstützt. Suchen Sie in der SSLAate CAA-Seite nach einer Liste solcher Anbieter. Wenn Ihr Provider aufgeführt ist, können Sie mit dem SSLMate CAA Record Generator eine Gruppe von CAA-Datensätzen generieren, in denen die CAs aufgelistet sind, die Sie zulassen möchten.

Wir haben aber gar keine CAA Einträge bei unserer Validierung benutzt 😉 Natürlich kann man da immernoch eine DNS Abfrage pro Zertvalidierung machen, aber rauskommt dann halt nichts. Ich vermute mal, daß genau der Fall „nichts“ aka. „Kein Ergebnis“ das eigentliche Problem war.

So oder so wundert es mich nicht, daß die Zahl von 4 Millionen auf 1.3 geschrumpt ist. Ich vermute, die geht eher in die zehntausende, als in die Millionen, wenn man die Fehlerquota bei uns als Maßstab ansetzt. Die Liste oben ist nur ein Auszug der Email, da waren noch viel mehr falsche Ergebnisse drin, als Ihr jetzt erahnen könnt 😉

(An.d.r.Ä. ein „nicht“ im ersten Absatz eingefügt.)

Let’s Encrypt gibt milliardstes Zertifikat aus \o/

Am 27.2. wurde die eine Milliarde SSL Zertifikate von Let’sEncrypt überschritten. Bei 46 Millionen Webseiten für die Zertifikate ausgestellt wurden, war das ja auch nur eine Frage der Zeit, wenn man 4 Zerts pro Jahr pro Domain durchbringen muß 🙂

Herzlichen Glückwunsch – Let’s Encrypt 😀

„We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates – one hundred million. One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody. Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though – we’ve made improvements across the board to provide even more secure and reliable service.“

Das selbstgesteckte Ziel haben Sie jedenfalls erreicht, das ist mal sicher. Ob das Netz wirklich sicherer geworden ist, ist eine andere Frage 😀

Let’s Encrypt Wildcard Zertifikate kommen später

Wie man der Community Ankündigung entnehmen kann, kommen die Wildcard Zerts von LE „später“ ™:

https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654

Eigentlich sollte es vorgestern schon losgehen, aber das wird erstmal verschoben. Neue Termine gibt es nicht. Als grund wird u.a. das Problem angegeben, das man über die TLS-SNI Erweiterung Zerts bekommen konnte, auch wenn man die gar nicht haben können sollte, so die Domain auf dem gleichen Shared-Hosting System war.

SNI erlaubt es, erstmal den Domainnamen zu senden, und der Server sucht dann das richtige Zertifikat raus, daß er dem Client präsentiert. Nicht zwingenderweise muß ein Client dann auch diese Domain als „Host:“ header angeben. Man kann also ein Zert bekommen, daß nicht zum Domainnamen paßt, dessen Inhalt man abrufen möchte.

 

Apache – Alles umleiten außer einem Pfad

Wer schon einmal eine Domain komplett z.b. auf https://domain.name umgeleitet hat, der kennt so einen Vhost Eintrag:

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    Redirect 301 / https://domain.name
</VirtualHost>

Was aber wenn man einen Pfad nicht umleiten kann/darf/will, weil das zu Problemen führen würde z.b. mit Lets Encrypt ?

Im Falle von Let’s Encrypt ist die Lösung ein negativer Pfadausschluß :

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    RedirectMatch 301 ^/((?!.well-known/acme-challenge).*)$ https://domain.name
</VirtualHost>

Damit wird alles, nur nicht der Pfad „/.well-kown/acme-challenge“ umgeleitet. Es ist für Lets Encrypt jetzt wieder möglich, die Challenges abzufragen.

Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀

 

Android 3.2 und das Let’s Encrypt Problem

Ich hab ja neulich auf HTTPS-Only Blog umgestellt, aber so ganz „Only“ geht es dann doch nicht.

Da die meisten RSS Feedleser für Handies die Zertifikate aus dem Truststore von Android benutzen, in dem Sie den internen Webbrowser benutzen um die Feeds anzuzeigen, kommt es mit Let’s Encrypt Zertifikaten zu Problemen: Die stehen da schlicht nicht drin. Wer da nicht drin steht, wird nicht angezeigt.

Das Problem habe ich bei meinen eigenen Android Programmen durch einen eigenen Truststore gelöst, der einfach die aktuellen Firefox Zertifikate bekommt. Das dieser Trick zwangsweise nur für eigene Programme funktioniert, mußte ich meinem Blog leider sagen, das Android weiterhin per Port 80 abrufen darf.

Und so geht so eine Ausnahme :

RewriteCond %{HTTP_HOST} .*marius\.bloggt-in-braunschweig\.de
RewriteCond %{SERVER_PORT}   !^443$
RewriteCond %{HTTP_USER_AGENT} !.*Android.3\.2.*
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]

 

Blog auf LE HTTPS umgestellt.

Ich habe mein Blog auf HTTPS mit einem Lets Encrypt Zertifikat umgestellt.

Falls Ihr mit den RSS Feeds Probleme beim Abholen bekommt, meldet Euch bitte.

Wie man das macht : )

Als erstes bestellen wir mal das Zertifikat :

/etc/httpd/letsencrypt/letsencrypt.sh -c -d marius.bloggt-in-braunschweig.de -d www.marius.bloggt-in-braunschweig.de

Obiges geht natürlich nur, wenn Ihr den Bash Clienten von Lets Encrypt auch dort instaliert habt.

Dann legen wir im Apache eine HTTPS Site an, z.B. hier : /etc/httpd/sites/1_marius.bloggt-in-braunschweig.de

<VirtualHost *:443>
    SSLProxyEngine On
    ServerName marius.bloggt-in-braunschweig.de
    ServerAlias *.marius.bloggt-in-braunschweig.de
    ... Sachen die Euch nichts angehen :) ...    
    Header always set Strict-Transport-Security "max-age=31556926 includeSubDomains" env=HTTPS
    SSLEngine on
    SSLInsecureRenegotiation off
    SSLProtocol TLSv1.2
    SSLHonorCipherOrder on
    SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!MD5:!aNULL:!EDH:!RC4:!RC4
    SSLCertificateKeyFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/privkey.pem
    SSLCertificateFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/cert.pem
    SSLCACertificateFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/chain.pem

</VirtualHost>

Und dann muß man seiner Site noch sagen, daß sie alle HTTP Zugriffe auf HTTPS umleiten soll, bevor diese stattfinden.

RewriteCond %{HTTP_HOST} ^www.marius.bloggt-in-braunschweig.de
RewriteRule (.*) https://marius.bloggt-in-braunschweig.de/$1 [R=301,L]

RewriteCond %{HTTP_HOST} .*marius\.bloggt-in-braunschweig\.de
RewriteCond %{SERVER_PORT}   !^443$
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]

Das meint, daß wer WWW. aufruf, auf den Hauptdomainnamen umgeleitet wird. (Am.d.R. www. braucht kein Mensch mehr)
Die zweite Anweisung leitet alles was nicht auf Port 443 ankommt, auf Port 443 um, so daß es verschlüsselt wird.

Das wars.

Jetzt bleibt nur die Frage zu klären: „Wieso hast Du auf https umgestellt, wo BIB.de doch ohnehin schon ein LE Zertifikat hatte ?“

Na weil das bei Subdomain nicht anders geht, da LE keine Wildcardzerts ausstellt und 100 Einträge im Hauptzertifikat sind auch irgendwann zu ende.

Firefox 50 wird Let’s Encrypt Root vertrauen

Let’s Encrypt hat bekannt gegeben, daß Mozilla das ROOT Zertifikat von Let’s Encrypt ab Firefox 50 als vertrauenswürdig anerkennt. Damit ist ein riesiger Schritt getan worden, LE als Trusted CA (Certificate Authority) zu etablieren. Normalerweise dauert es  3-6 Jahre bis das ROOT Zertifikat einer Organisation so starkes Vertrauen genießt, daß es von Browsern akzeptiert wird.  LE hat es in wenigen Monaten geschafft.

Quelle: https://letsencrypt.org/2016/08/05/le-root-to-be-trusted-by-mozilla.html

Let’s Encrypt

Unter dem Motto Let’s Encrypt betreibt Mozilla zusammen mit Cisco u.a. eine Zertifizierungstelle bei der kostenlose domainvalidierte Zertifikate für die eigene Domain bestellt werden können.

Die Unterstützung für diese Plattform durfte ich Anfang der Woche bauen und bin dabei wiederholt an „neumodischen“ Erscheinungen hängen geblieben. In der guten alten Zeit hat man sich den Source einer Anwendung von der Webseite des Autors, Sourceforge o.ä. gezogen, kurz konfiguriert und dann kompiliert.

Heute klappt sowas nicht mehr, weil fast jedes Projekt gleich mehrere Frameworks einsetzt, die weder in den Readmes aufgeführt sind, noch sauber laufen. So mancher Webseite, die behauptet, das Projekt kurz kompiliert zu haben, kann man dabei kein Wort mehr trauen. Zumal es dann immernoch scheitern kann, selbst wenn das Lieblings OS einige Frameworks wie NodeJS, liefern kann.

Bis man sich die Einzelteile für ein kleines Projekt zusammen gesucht hat, können Stunden vergehen. Dabei spielt es keine Rolle, ob das Zielprogramm in Python, Java oder Javascript geschrieben wurde.

Zum Glück gibt es immer noch Menschen, die möglicherweise ungewollt, alles richtig machen, und keine skurrilen Abhängigkeiten in Ihre Projekte einbauen. Am Beispiel von Let’s Encrypt Tools ist letztendlich das primitivste Tool, daß „beste“ geworden: schneller Download, keine skurrilen Abhängigkeiten, und in der Alpha schon 100% zweckgeeignet naja und der beste Vorteil von allen, es ein Bashscript 🙂 Damit läuft es natürlich auf allen Linuxen sofort.Man muß es halt nur finden 😀

Am Ende bleibt nur zu hoffen, dann diese Abhängigkeitsfanatiker mit Ihren Projekten genauso schnell verschwinden, wie sie aufgetaucht sind. Outsourcing hat halt nicht nur Vorteile.