Die meisten werden Let’s Encrypt als freie und kostenlose Zertifizierungsstelle kennen. Let’s Encrypt nutzt das ACME (Automatic Certificate Management Environment) Protokoll um mit minimalen administrativen Aufwand gültige Zertifikate für alle möglichen Dienste und Systeme auszustellen.
Let’s Encrypt eignet sich dabei besonders für alle Systeme und Dienste die öffentlich erreichbar sind, da hier der Ausstellungsprozess für die Zertifikate sehr einfach ist. Let’s Encrypt eignet sich allerdings weniger für interne Systeme welche nicht direkt im Internet erreichbar sind. Zwar bietet Let’s Encrypt bzw das ACME Protokoll auch dafür Lösungen an, aber diese lassen sich meist für rein interne Systeme nur aufwändig oder gar nicht nutzen.
Für rein interne Systeme kann aber eine ACME kompatible Zertifizierungsstelle wie die Step CA verwendet werden. Somit lassen sich auch für interne Systeme Zertifikate auf einfache und automatische Weise nutzen.
In diesem Artikel wird eine Step CA als Sub CA (Zwischenzertifizierungsstelle) für eine Windows Root CA (Stammzertifizierungsstelle) konfiguriert. So lässt sich das ACME Protokoll auch intern nutzen und Zertifikate können für Windows und Linux Dienste automatisiert werden.
Installation Step CA
Die Installation der Step CA auf einem Ubuntu Server ist schnell erledigt. Um es im weiteren Verlauf etwas einfacher zu machen, habe ich den Ordner /tmp/step erzeugt, diesen Ordner nutze ich auch später für den Dateiaustausch. Hier einmal die Schritte zur Installation der Step CLI und Step CA:
mkdir /tmp/step
cd /tmp/step
wget https://dl.smallstep.com/cli/docs-ca-install/latest/step-cli_amd64.deb
sudo dpkg -i step-cli_amd64.deb
wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb
sudo dpkg -i step-ca_amd64.deb
Wenn die Installation erfolgreich war, sollten die folgenden beiden Befehle die Version ausgeben:
step version
step-ca version
Initialkonfiguration Step CA
Nach der Installation der Step CA kann die Initialkonfiguration durchgeführt werden. Ein Assistent hilft bei der Einrichtung und es müssen nur ein paar Fragen beantwortet werden. Die Konfiguration kann mit dem folgenden Befehl gestartet werden:
step ca init
Meine Konfiguration erkennt man im Screenshot. Wichtig wird hier der DNS Name, ich habe für diesen Beispiel den DNS Namen acme.frankysweblab.de gewählt. Ich würde aber einen Namen wie stepca.frankysweblab.de oder subca.frankysweblab.de empfehlen, denn die Step-CA kann mehrere Protokolle anbieten (nicht nur ACME). Ich habe acme.frankysweblab.de nur wegen der einfacheren Unterscheidung genommen.
Das Passwort muss man sich hier übrigens nicht merken. Hier einmal der Screenshot der Konfiguration:
Die Step CA ist nun eine eigene Root-CA, dies wird im nächsten Teil geändert.
Step CA als Sub CA der eigenen Root CA konfigurieren
Damit Active Directory Clients die neue CA und deren Zertifikate als gültig akzeptieren, kann die Step CA als Sub CA der Root CA konfiguriert werden. Die Step CA ist somit keine Root CA mehr, sondern eine Sub CA. Die Step CA muss daher von der Root CA signiert werden, dazu ist ein CSR (Certificate Signing Request) und ein wenig Konfiguration nötig:
sudo su
rm ~/.step/secrets/root_ca_key
rm ~/.step/certs/root_ca.crt
step certificate create "FrankysWeb-ACME-CA" intermediate.csr intermediate_ca_key --csr
Das Passwort für den private Key sollte man sich nun merken, es wird später benötigt. Die Datei intermediate.csr enthält nun den CSR, welcher von der Root CA signiert werden muss:
Die Datei intermediate.csr muss nun auf die Root CA kopiert werden. Am besten legt man sich auf der Root CA einen Ordner an, denn im folgenden müssen ein paar Dateien ausgetauscht werden.
Auf der Root CA kann nun das Root-CA Zertifikat exportiert werden:
Das Zertifikat muss im BASE64 Format exportiert werden. Als Name kann direkt root.crt angegeben werden:
Im Ordner sollten sich nun zwei Dateien befinden, das exportierte Root Zertifikat und der CSR der Step CA:
Der CSR der Step CA (intermediate.csr) muss nun von der Root-CA signiert werden. Dazu kann der folgende Befehl verwendet werden:
certreq -submit -attrib "CertificateTemplate:SubCA" intermediate.csr intermediate.crt
Im Ordner sollten sich nun 4 Dateien befinden:
Die 4 Dateien müssen nun auf die Step CA in den Ordner /tmp/step kopiert werden. Sobald die Dateien auf die ACME CA kopiert wurden, können die Dateien an die richtigen Stellen kopiert werden. Dazu können die folgenden Befehle benutzt werden:
mv root.crt ~/.step/certs/root_ca.crt
mv intermediate.crt ~/.step/certs/intermediate_ca.crt
mv intermediate_ca_key ~/.step/secrets/intermediate_ca_key
Hinweis: Die Datei intermediate_ca_key wurde vorher mit dem Befehl „step certificate create“ erstellt und befindet sich bereits im Verzeichnis /tmp/step.
Die CA kann nun einmal testweise mit dem Befehl „step-ca“ gestartet werden. Beim Start muss das zuvor festgelegte Passwort eingegeben werden. Wenn es bis hierher erfolgreich war, sollte die Ausgabe wie folgt aussehen:
Auf dem DNS Server kann jetzt der entsprechende DNS Eintrag erstellt werden. Ich habe beim Befehl „step ca init“ den Namen acme.frankysweblab.de angegeben, daher habe ich dazu einen HOST-A Eintrag mit der IP der ACME CA erstellt:
Im Browser kann nun die CA via https aufgerufen werden. Zwar liefert die CA nur ein „404 page not found“, aber hier sollte kein Zertifikatsfehler auftauchen:
Wie zu sehen ist, meckert der Browser nicht das Zertifikat an, da die CA FrankysWeb-ACME-CA über die eigene Root-CA FrankysWeb-Root-CA signiert wurde.
Step CA als Deamon konfigurieren
Damit die Step CA nach Start des Betriebssystem ebenfalls gestartet wird, kann die CA als Deamon konfiguriert werden. Dazu muss zunächst das Passwort für den privaten Schlüssel in einer Datei gespeichert werden:
echo 'Geheim123!' > /root/.step/.ca-pw
Jetzt kann der Deamon erstellt werden:
cat > /etc/systemd/system/step-ca-server.service <<EOF
[Unit]
Description=step-ca-server
After=network-online.target
Wants=network-online.target
[Service]
TimeoutStartSec=0
ExecStart=/usr/bin/step-ca --password-file=/root/.step/.ca-pw /root/.step/config/ca.json
ExecReload=kill -s sighup $(ps aux | grep 'step-ca' | grep json | tr -s ' ' | cut -f 2 -d ' ')
ExecStop=kill -9 $(ps aux | grep 'step-ca' | grep json | tr -s ' ' | cut -f 2 -d ' ')
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
EOF
# Reload systemd
systemctl daemon-reload
# Start Step CA
systemctl enable --now step-ca-server
Mit dem folgenden Befehl kann geprüft werden, ob die Step CA gestartet ist:
systemctl status step-ca-server
So sieht es aus, wenn hier alles geklappt hat:
ACME Protokoll aktivieren
step ca provisioner add acme --type=ACME --x509-max-dur=4320h --x509-default-dur=744h --force-cn
Der Deamon muss nun neu gestartet werden:
systemctl restart step-ca-server
systemctl status step-ca-server
In einem Browser sollte sich nun die folgende URL öffnen lassen:
https://<CA-DNS-NAME>/acme/acme/directory
Auch hier darf es wieder keine Zertifikatswarnung geben.
Zertifikat auf Windows Rechnern via Win-ACME anfordern
Für Windows Systeme gibt es den Windows ACME Client (win-acme oder WACS). Win-ACME übernimmt auch gleich die Konfiguration von verschiedenen Diensten wie Exchange, IIS, Apache oder RDS und kümmert sich um das automatische Erneuerern von Zertifikaten. WIN-ACME kann hier runtergeladen werden:
Nach dem Entpacken findet sich die Datei settings_default.json im win-acme Verzeichnis. In dieser Datei müssen die Werte für „DefaultBaseUri“, „DefaultBaseUriTest“ und „DefaultBaseUriImport“ mit der URL der CA angepasst werden. Hier wird die entsprechende URL der Step CA eingetragen:
https://<CA-DNS-NAME>/acme/acme/directory
Danach kann win-acme gestartet werden. Der folgende Screenshot zeigt win-acme auf einem IIS Webserver. In der vierten Zeile ist zu erkennen, dass die Verbindung erfolgreich hergestellt wurde. Win-acme fordert nun ein Zertifikat von der Step CA an und konfiguriert auch direkt den IIS Webserver. Die Erneuerung des Zertifikats läuft nun ebenfalls automatisch:
Das Zertifikat wird für den entsprechenden DNS Namen des Servers ausgestellt. In diesem Fall hat win-acme die http-01 Challenge benutzt. Es ist aber auch möglich dns-01 oder tls-alpn-01 zu benutzen:
Hier einmal der Screenshot der Zertifikatskette:
Zertifikat auf Ubuntu Rechnern via Certbot anfordern
Auf Ubuntu oder anderen Linux Systemen ist certbot ein beliebter ACME Client. Certbot kann mit den folgenden beiden Befehlen installiert werden, hier wird auch gleich das Paket ca-certificates installiert, damit das Root Zertifikat auf dem Ubuntu Server installiert werden kann:
apt install python3-pip ca-certificates
pip install certbot
Nach der Installation von Certbot muss zunächst das Root Zertifikat installiert werden, dies kann mit den folgenden beiden Befehlen erledigt werden:
wget https://acme.frankysweblab.de/roots.pem -O /usr/local/share/ca-certificates/frankysweblab-acme.crt --no-check-certificate
sudo update-ca-certificates
Die Befehle müssen entsprechend mit den eigenen URLs bzw. Dateinamen benutzt werden. Danach lässt sich ein Zertifikat via Certbot anfordern:
certbot certonly -n --standalone -d acme.frankysweblab.de --server https://acme.frankysweblab.de/acme/acme/directory --agree-tos --email admin@frankysweblab.de
Das automatische Erneuern funktioniert via Cronjob. Dazu kann mit dem Befehl „crontab -e“ die folgende Zeile hin zugefügt werden:
*/15 * * * * root certbot -q renew
Ab jetzt wird alle 15 Minuten geprüft, ob ein Zertifikat erneuert werden muss.
Fazit
Das ACME Protokoll eignet sich auch für interne Systeme und Services und vereinfacht den Umgang mit Zertifikaten enorm. Im besten Fall muss man sich kaum noch um das Thema Zertifikat kümmern, da die ACME Clients wie win-acme und certbot nahezu alle Arbeit abnehmen. Auch viele Appliances unterstützen Let’s Encrypt und damit ACME Protokoll, beispielsweise kann auch ein Kemp Loadbalancer eine interne ACME CA verwenden:
Leider lässt Kemp nur eine Konfiguration zu, Kemp kann also entweder das öffentliche Let’s Encrypt oder die eigene ACME CA verwenden. Trotzdem ist die Step CA und das ACME Protokoll perfekt geeignet um mit minimalen Aufwand all seine internen Dienste mit gültigen Zertifikaten auszustatten. Die öffentlichen Dienste können Let’s Encrypt verwenden, die internen Dienste die eigene ACME CA. So erhält man alle Zertifikate, ob intern oder öffentlich, kostenlos.
hey franky,
vielen dank für die anleitung, das klappt super soweit – nur eine Sache wundert mich doch total und funktioniert auch bei uns dadurch unsauber: Die Certificate sind nur 30 Tage gültig -> Cerbot kommt dadurch aber ins Stocken, da er -30 Days Valid erneuert und bezeichnet sie andauernd als noch nicht due for renew selbst wenn er ein Tag vor Schluss ist.
In deine Konsolen Outputs glaube ich auch zu erkennen, dass sie ähnlich lange valid sind.
Hast du ne Idee woher das kommt (normalerweise sind ja letsencrypt certs 90 tage gültig)
VG
und start zu fragen, sollte man mal selber suchen…
im config folder von step (zu finden mit step path) findet sich die ca.json dort gibt es den Wert für „defaultTLSCertDuration“:
den einfach wie gewünscht angepasst – oder sieht da wer ein problem?
Sehr interessantes Thema. Vielen Dank für den ausführlichen Einblick!