
Das Unternehmen LetsEncrypt, das kostenlose SSL-Zertifikate zur Verschlüsselung anbietet, sieht sich gezwungen, einige Zertifikate zu annullieren.
Das Problem steht im Zusammenhang mit in der Verwaltungssoftware Boulder, die für die Erstellung von CA verwendet wird. Normalerweise erfolgt die Überprüfung des CAA-DNS-Eintrags gleichzeitig mit der Bestätigung des Domainbesitzes, und die meisten Abonnenten erhalten das Zertifikat sofort nach der Überprüfung. Die Entwickler der Software haben jedoch festgelegt, dass das Überprüfungsergebnis als bestanden gilt, noch bis zu 30 Tage danach. In einigen Fällen kann eine zweite Überprüfung der Einträge kurz vor der Ausstellung des Zertifikats erforderlich sein, insbesondere ist eine erneute Überprüfung des CAA innerhalb von 8 Stunden vor der Ausstellung nötig. Daher muss jede Domain, die vorher überprüft wurde, erneut überprüft werden.
Was ist also der Fehler? Wenn die Zertifikatsanfrage N Domains enthält, die eine erneute Überprüfung des CAA erfordern, wählte Boulder eine davon aus und überprüfte sie N-mal. Infolgedessen bestand die Möglichkeit, ein Zertifikat auszustellen, selbst wenn später (bis X+30 Tage) ein CAA-Eintrag gesetzt wurde, der die Ausstellung von LetsEncrypt-Zertifikaten verbietet.
Zur Überprüfung der Zertifikate hat das Unternehmen , das einen detaillierten Bericht anzeigt.
Erfahrene Benutzer können alles selbst erledigen, indem sie die folgenden Befehle verwenden:
# проверка https
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# вариант проверки от @simpleadmin
echo | openssl s_client -connect example.com:443 |& openssl x509 -noout -serial
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:25 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:587 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:143 -starttls imap -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:993 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# в принципе аналогично проверяются и другие сервисыAls Nächstes sollten Sie nach Ihrer Seriennummer suchen, und wenn sie auf der Liste steht, wird empfohlen, das/ die Zertifikat(e) zu aktualisieren.
Um die Zertifikate zu aktualisieren, kann certbot verwendet werden:
certbot renew --force-renewalDas Problem wurde bereits am 29. Februar 2020 gefunden, um das Problem zu lösen, wurde die Ausstellung von Zertifikaten von 3:10 UTC bis 5:22 UTC ausgesetzt. Laut interner Untersuchung wurde der Fehler am 25. Juli 2019 eingeführt, ein detaillierter Bericht wird später von der Firma bereitgestellt.
UPD: Der Online-Zertifikatsprüfservice könnte mit russischen IP-Adressen nicht funktionieren.
Quelle: habr.com
