Schummelzettel: SSL Zertifikate

Wir werden das Thema SSL sicher noch häufiger behandeln, aber heute beschränken wir uns auf einen kleinen Schummelzettel - für alle, die sich nicht mit Spezialfällen konfrontiert sehen, sondern einfach vor der (meist jährlichen) Aufgabe stehen, ein SSL Zertifikat zu tauschen.

Vorweg: PEM, CA-Bundle, CSR, Keys - was ist das alles?

Die verschiedenen Dateien erklären sich durch den Ablauf wie ein Zertifikat ausgestellt wird:

• Man generiert eine Schlüsseldatei für das Zertifikat
  Diese verbleibt auf dem Server und ermöglicht ihm, es zu verwenden. Er ist genauso sicher zu behandeln, wie ein persönlicher SSH private key, das heißt, er sollte nur verschlüsselt übertragen werden, falls das notwendig ist. (Er sollte auch nur für root les-/schreibbar sein!)
• Mittels der Schlüsseldatei generiert man ein CSR - Certificate Signing Request
  Das CSR enthält den öffentlichen Teil des Keys, die Angabe, für welche Domain das Zertifikat ausgestellt wird und (oft optionale) Angaben zur Organisation.
• Das CSR wird bei einer Certificate Authority (CA) eingereicht
  Wie der Name erraten lässt, ist eine Certificate Authority befugt, Zertifikate auszustellen. Diese Befugnis wird ihr wiederum von einer der Root Certificate Authorities verliehen - daraus ergibt sich auch das CA-Bundle bzw. die sogenannte Certificate Chain. Das Bundle enthält alle Zwischen-Zertifikate, die notwendig sind, diese Befugnis nachzuvollziehen.
• Die Certificate Authority validiert den Request und stellt das Zertifikat aus
  Bei Domain Control Validated Zertifikaten muss bewiesen werden, dass man die Domain, für die angefragt wird, auch tatsächlich betreibt. Das passiert in der Regel über die Hinterlegung einer vorgegebenen Datei unter einer bestimmten URL, kann aber auch über einen DNS-Eintrag oder per E-Mail erfolgen. Neben der Domain Control Validation gibt es auch Organisation und Extended Validation Zertifikate. Dabei sind auch Informationen zum Unternehmen zu belegen um sicherzustellen, dass man auch berechtigt ist, ein Zertifikat für diese Organisation zu beantragen.

Muss ich bei der Verlängerung eines Zertifikats eine neue Schlüsseldatei erstellen?

Rein technisch gesehen nicht, man kann auch mit einer bestehenden Schlüsseldatei ein neues CSR erstellen oder sogar das alte CSR wiederverwenden, wenn sich die Domain-/Firmendaten nicht geändert haben. Aus Sicherheitsgründen empfehlen wir immer auch den Schlüssel neu zu erstellen (und praktizieren das bei unseren Verlängerungen auch so).

PEM? Mein Zertifikat endet aber in .crt!

Die kurze Antwort - macht nichts. .cer, .crt oder .pem sind alles gängige Endungen für Base64 mit ASCII-Zeichen kodierte X.509-Zertifikate, wie sie zum Beispiel von Apache, nginx oder postfix verwendet werden.

Wieso sollte mein Zertifikat auch seine Chain enthalten?

Ein Client soll ohne zusätzliche Nachfragen die Gültigkeit eines Zertifikats prüfen können. Daher muss immer auch die gesamte Unterschriftenkette, mit Ausnahme des root Zertifikats selbst, zur Verfügung gestellt werden. Die root Zertifikate selbst sind im Client hinterlegt, entweder im Betriebssystem oder etwa im Browser-eigenen Zertifikats-Speicher, wodurch es dem Client überhaupt erst möglich ist, offiziell validierte Zertifikate zu erkennen.

Je nach Service kann man die Zertifikatskette entweder als extra Datei angeben (zum Beispiel unter Apache "SSLCertificateChainFile") oder man kopiert das Domain-Zertifikat und seine Kette in eine Datei zusammen, und bindet diese ein.

Ein nützliches Tool zum Überprüfen ob die Kette vollständig enthalten ist findet sich bei ssllabs.com.

curl zeigt das Problem auch auf:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Häufig gebrauchte Befehle

Wie lese ich ein Zertifikat aus?

Nur Aussteller, Gültigkeitsdatum und alternative Namen ausgeben:

$ openssl x509 -in domain.at.crt -dates -subject -issuer -ext subjectAltName -noout
    notBefore=Jan 1 00:00:00 2021 GMT
    notAfter=Jan 1 23:59:59 2022 GMT
    subject=CN = domain.at
    issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
    X509v3 Subject Alternative Name: 
    DNS:domain.at, DNS:www.domain.at

Oder eine vollständigere Ausgabe mit Fingerprints:

$ openssl x509 -in domain.at.crt -noout -text

Wie lese ich ein CSR aus?

Domainname und Organisationsdaten ausgeben:

$ openssl req -noout -text -in domain.at.csr 
Certificate Request:
     Data:
          Version: 1 (0x0)
          Subject: C = AT, ST = XXX, L = XXX, O = Organisation, CN = domain.at
          Subject Public Key Info:
          (...)

Wie überprüfe ich einen Key?

Die Integrität des Keys prüfen:

$ openssl rsa -in star.toscom.at.key -check -noout
RSA key ok

Wie prüfe ich, ob Zertifikat, CSR und Key zusammenpassen?

Man kann den MD5 Hash vergleichen, um zu prüfen, ob die Dateien zusammengehören. Das empfiehlt sich immer, wenn es sein kann, dass Dateien durcheinander gekommen sind, oder wenn sie getrennt voneinander erstellt wurden - passen Zertifikat und Key nicht zusammen, startet der betroffene Service nicht!

$ openssl x509 -noout -modulus -in domain.at.crt | openssl md5
(stdin)= f0d93054985294272dc75cf661ae6519
$ openssl rsa -noout -modulus -in domain.at.key | openssl md5
(stdin)= f0d93054985294272dc75cf661ae6519
$ openssl req -noout -modulus -in domain.at.csr | openssl md5
(stdin)= f0d93054985294272dc75cf661ae6519

Wie prüfe ich, welches Zertifikat ein Server ausliefert?

Bei HTTPS ist das natürlich per Browser möglich (shift-reload bzw. Incognito-Modus nicht vergessen!), bei Mail- oder FTP-Servern ist nmap eine bequeme Möglichkeit. Es muss nicht berücksichtigt werden, ob STARTTLS zum Einsatz kommt und es liefert kompakten Output:

$ nmap --script ssl-cert -p 25 mail.domain.at
(...)
PORT STATE SERVICE
25/tcp open smtp
| ssl-cert: Subject: commonName=mail.domain.at
| Subject Alternative Name: DNS:mail.domain.at
| Issuer: commonName=R3/organizationName=Let's Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-01-01T12:04:48
| Not valid after: 2022-01-01T12:04:48

Mit openssl s_client ist die Abfrage auch möglich, aber zum Beispiel muss man für das Ablaufdatum den Output dann nochmals durch openssl pipen:

$ openssl s_client -showcerts -connect mail.domain.at:25 -starttls smtp | openssl x509 -noout -dates

Und als Bonus-Schummelzettel hier noch die gängigsten Ports:
HTTPS 443, SMTP TLS 587, SMTP SSL 465, POP3 SSL 995, IMAP StartTLS 143, IMAP SSL 993, FTPS 21.

Wieso liefert mein Server nach dem Tausch trotzdem noch das alte Zertifikat aus?

Das müsste man natürlich detailliert Troubleshooten, aber in der Praxis decken hier zwei Fragen fast alle Problemfälle ab:

• Wurde der Service restartet? (Ein reload reicht nicht immer aus!)
• Gibt es einen vorgeschalteten Proxy, Load-Balancer, CDN oder ähnliches, auf dem das Zertifikat auch noch getauscht werden muss?