Changes for page Server-Zertifikat
Last modified by Jonas Jelten on 2024/08/23 12:30
From version 5.1
edited by Jonas Jelten
on 2023/05/25 12:47
on 2023/05/25 12:47
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. jelten1 +XWiki.fahrbach - Content
-
... ... @@ -4,7 +4,7 @@ 4 4 5 5 Es werden verschiedene Fälle unterschieden: 6 6 7 -cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]] 7 + cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]] 8 8 9 9 * cit/in/ma.tum.de Domains auf anderen Maschinen: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions) oder [[rbg-cert selber einrichten|Informatik.Benutzerwiki.ServerZertifikate|anchor="Serverzertifikat_f_252r_alle_anderen_Maschinen_44_deren_Namen_252ber_die_Strukturdb_verwaltet_werden"]] 10 10 * andere Domains: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions) ... ... @@ -16,18 +16,19 @@ 16 16 Für neue VMs ist die erforderliche Software bereits vorinstalliert. 17 17 18 18 1 In der [StrukturDB](https://rbgwebapp.in.tum.de/struktur/) müssen alle Aliase korrekt eingetragen sein. Bei Service-IPs muss `servicehost` auf den tatsächlichen Host (also Server/VM/...) verweisen. 19 -1 Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen 20 -1 Um auf der Maschine die Dienste neuzustarten/neuzuladen, wenn ein neues Zertifikat da ist, legt man scripte in `/usr/local/cert.d/` ab, die mit `run-parts(8)` kompatibel sind. Das erste Argument ist der Teilpfad zum neuen Zertifikat. Unten ist ein Beispielscript für einen Apache2-reload. 21 -1 Nun kann man mit `rbg-cert` Zertifikate beantragen: 19 + 1 Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen 20 + 1 Um auf der Maschine die Dienste neuzustarten/neuzuladen, wenn ein neues Zertifikat da ist, legt man scripte in `/usr/local/cert.d/` ab, die mit `run-parts(8)` kompatibel sind. Das erste Argument ist der Teilpfad zum neuen Zertifikat. Unten ist ein Beispielscript für einen Apache2-reload. 21 + 1 Nun kann man mit `rbg-cert` Zertifikate beantragen: 22 22 23 - ```24 -# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen! 23 +{{html wiki="true"}} 24 +{{code}}# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen! 25 25 rbg-cert --show 26 -# Initiale Beantragung oder nach Namens änderung neues Zertifikat beantragen:26 +# Initiale Beantragung oder nach Namensänderung neues Zertifikat beantragen: 27 27 rbg-cert --force-request 28 -# Nach ein paar Minuten das Zertifikat downloaden (oder man wartet bis der systemd-timer l äuft):28 +# Nach ein paar Minuten das Zertifikat downloaden (oder man wartet bis der systemd-timer läuft): 29 29 rbg-cert 30 -``` 30 +{{/code}} 31 +{{/html}} 31 31 32 32 `rbg-cert.service` und `rbg-cert.timer` **verlängern** das Zertifikat automatisch 30 Tage vor Ablauf. 33 33 ... ... @@ -42,14 +42,17 @@ 42 42 43 43 Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`: 44 44 45 -``` 46 +{{html wiki="true"}} 47 +{{code}} 46 46 SSLCertificateFile /etc/apache2/tls/fullchain.pem 47 47 SSLCertificateKeyFile /etc/apache2/tls/key.pem 48 -``` 50 +{{/code}} 51 +{{/html}} 49 49 50 50 Und der automatische renew-hook (`chmod +x` nicht vergessen!) 51 51 52 -``` 55 +{{html wiki="true"}} 56 +{{code}} 53 53 $ cat /usr/local/cert.d/apache2 54 54 #!/bin/bash 55 55 set -o nounset ... ... @@ -63,12 +63,13 @@ 63 63 install --mode 0644 "$1".fullchain.pem /etc/apache2/tls/fullchain.pem 64 64 65 65 systemctl reload apache2.service 66 -``` 70 +{{/code}} 71 +{{/html}} 67 67 68 68 ### Beispiel für nginx 69 69 70 - ```71 -$ cat /etc/nginx/conf.d/ssl.conf 75 +{{html wiki="true"}} 76 +{{code}}$ cat /etc/nginx/conf.d/ssl.conf 72 72 # config from https://mozilla.github.io/server-side-tls/ssl-config-generator/ 73 73 74 74 ssl_certificate /etc/nginx/tls/fullchain.pem; # cert + parent CAs except root CA ... ... @@ -90,11 +90,13 @@ 90 90 91 91 add_header X-XSS-Protection "1; mode=block"; 92 92 add_header X-Content-Type-Options nosniff; 93 -``` 98 +{{/code}} 99 +{{/html}} 94 94 95 95 Und der renew-hook (`chmod +x` nicht vergessen!) 96 96 97 -``` 103 +{{html wiki="true"}} 104 +{{code}} 98 98 $ cat /usr/local/cert.d/nginx 99 99 #!/bin/bash 100 100 set -o nounset ... ... @@ -108,12 +108,13 @@ 108 108 install --mode 0644 "$1".fullchain.pem /etc/nginx/tls/fullchain.pem 109 109 110 110 systemctl reload nginx.service 111 -``` 118 +{{/code}} 119 +{{/html}} 112 112 113 113 ### Allgemeines Beispiel 114 114 115 - ```116 -$ cat /usr/local/cert.d/yourservice 123 +{{html wiki="true"}} 124 +{{code}}$ cat /usr/local/cert.d/yourservice 117 117 #!/bin/bash 118 118 set -o nounset 119 119 set -o errexit ... ... @@ -124,7 +124,8 @@ 124 124 #install --mode 0644 --owner myowner "$1".chain.pem /etc/mydaemon/tls/chain.pem 125 125 #install --mode 0644 --owner myowner "$1".fullchain.pem /etc/mydaemon/tls/chainwithcert.pem 126 126 #systemctl reload mydaemon 127 -``` 135 +{{/code}} 136 +{{/html}} 128 128 129 129 ## Serverzertifikat für alle anderen Maschinen, deren Namen über die Strukturdb verwaltet werden 130 130 ... ... @@ -137,8 +137,8 @@ 137 137 Das Programm `rbg-cert` verwendet auch die API, d.h. man kann es auf andere Maschinen portieren. 138 138 Zur Vorbereitung auf den Einsatz von rbg-cert sind folgende Schritte notwendig: 139 139 140 - ```141 -echo $UQN > /etc/uqn 149 +{{html wiki="true"}} 150 +{{code}}echo $UQN > /etc/uqn 142 142 apt install strongswan-pki 143 143 apt install python3-cryptography 144 144 ... ... @@ -151,7 +151,8 @@ 151 151 152 152 pki --pub --in $UQN.privkey.pem --outform pem > $UQN.pubkey.pem 153 153 # Diesen pubkey dann in der StrukturDB für PIRA registrieren 154 -``` 163 +{{/code}} 164 +{{/html}} 155 155 156 156 `rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren. 157 157 ... ... @@ -165,12 +165,13 @@ 165 165 166 166 Production: 167 167 168 - ```169 -URL: https://pira.in.tum.de/v0/server/[UQN] 178 +{{html wiki="true"}} 179 +{{code}}URL: https://pira.in.tum.de/v0/server/[UQN] 170 170 171 - GET →{cert, chain, fullchain, names, should_renew}181 + GET → {cert, chain, fullchain, names, should_renew} 172 172 POST {csr} 173 -``` 183 +{{/code}} 184 +{{/html}} 174 174 175 175 Hier sind keine Tests zulässig. 176 176 ... ... @@ -180,14 +180,13 @@ 180 180 181 181 Manuelle Ausstellung mit Genehmigung durch RBG nur möglich, wenn technisch weder rbg-cert noch Let's Encrypt möglich sind: 182 182 183 -1. Auf dem Zielserver z.B. nach `/etc/ssl/private` 184 -1. Certificate Signing Request (`csr`) erzeugen 185 -`openssl req -newkey rsa:3072 -nodes -keyout SERVERNAME.key -out SERVERNAME.csr -subj '/C=DE/O=Technische Universitaet Muenchen/CN=SERVERNAME.cit.tum.de'` 186 - - weitere namen in csr packen: `-addext "subjectAltName = DNS:OTHERNAME.cit.tum.de, DNS:ANOTHERNAME.cit.tum.de"` 187 -1. [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN): 188 - 1. `.csr` hochladen 189 - 1. unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen 190 - 1. alle anderen Felder leer lassen 191 -1. Bitte den `commonName` (CN) mit Begründung warum rbg-cert und Let's Encrypt nicht möglich sind per E-Mail an <rbg@in.tum.de> schicken. 192 -1. auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen 193 -1. [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)" 194 +1 Auf dem Zielserver z.B. nach `/etc/ssl/private` wechseln 195 + 1 Certificate Signing Request (`csr`) erzeugen 196 + 197 + 1 [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN): 198 + 1 `.csr` hochladen 199 + 1 unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen 200 + 1 alle anderen Felder leer lassen 201 + 1 Bitte den `commonName` (CN) mit Begründung warum rbg-cert und Let's Encrypt nicht möglich sind per E-Mail an rbg@in.tum.de schicken. 202 + 1 auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen 203 + 1 [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)"