Keeping your SAN-ity: SANs korret mit EasyRSA 3.2.x einbetten

Interne SSL-Zertifikate zu erneuern ist nur für wenige Administratoren Alltag, aber alle Jahre wieder nötig. Auch bei uns stand die Erneuerung unserer Certificate Authority (CA) für die Backend-Server an. Wir haben uns dazu entschieden, eine aktuelle Version von EasyRSA zu verwenden – und die Umstellung kam natürlich mit einigen Stolpersteinen.

Während das Erneuern der eigentlichen CA reibungslos verlief, ist uns aufgefallen, dass die für uns benötigten Subject Alternative Names (SAN) nicht in neu ausgestellten Zertifikaten eingebettet waren.

Was ist schiefgelaufen?

Wie sich herausstellte, ist ein wenig zusätzliche Konfiguration nötig, damit die SAN-Einträge im Zertifikat landen. Dieser Blogpost dokumentiert grob die Änderungen gegenüber älteren EasyRSA-Versionen und kann auch als allgemeiner Leitfaden für das Einbetten von SAN-Einträgen verwendet werden.

Erster Lösungschritt: SAN-Variablen richtig setzen

IIn unserer alten EasyRSA-Version wurden die SAN-Einträge in der openssl-Konfiguration unter der [alt_names]-Sektion mit durchnummerierten Einträgen (DNS.1=hostname1, DNS.2=hostname2, …) gepflegt. Aktuelle EasyRSA-Versionen weigern sich jedoch, diese Liste weiterzuverwenden.

Stattdessen soll die Umgebungsvariable EASYRSA_SAN gesetzt werden. Das wäre natürlich direkt beim Aufruf des Skripts möglich, ist bei längeren SAN-Listen jedoch unhandlich.

Die für uns sauberste Lösung war, die SANs in der vars-Datei von EasyRSA als Shell-Array zu definieren:

SAN_LIST=(
  "DNS:backend.host"
  "DNS:app1.42ways.de"
  "DNS:app2.42ways.de"
  "DNS:wiki.42ways.de"
  ...
)

set_var EASYRSA_SAN "$(IFS=,; echo "${SAN_LIST[*]}")"

Damit lassen sich die Hostnamen bequem ein- oder auskommentieren und auch logisch gruppieren. EasyRSA sorgt dann dafür, den Array in einen passenden String für OpenSSL zu erweitern.

Die Einträge waren nun zwar als Parameter beim Signieren sichtbar, fehlten aber dennoch im fertigen Zertifikat. Es musste also noch ein Puzzleteil ergänzt werden:

$EASYRSA_SAN in x509-types referenzieren

EasyRSA verwendet verschiedene Profile, um Zertifikate auszustellen. Diese finden sich im Verzeichnis x509-types. Standardmäßig enthält das Server-Profil Basis- und sinnvolle erweiterte Attribute, SAN-Unterstützung ist aber nicht dabei. Das bedeutete, dass unsere SANs während der Request-Generierung sichtbar waren, beim eigentlichen Signieren jedoch stillschweigend ignoriert wurden.

Die Lösung ist einfach: Das entsprechende Profil muss explizit angewiesen werden, die Umgebungsvariable $EASYRSA_SAN zu verwenden:

[ server_ext ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
subjectAltName = $ENV::EASYRSA_SAN

Ergebniss

Mit diesen Änderungen wird eine einfach verwaltbare Liste von SAN-Einträgen wieder korrekt in ausgestellte Zertifikate eingebettet, und TLS-Clients können diese ordnungsgemäß validieren..