Changes for page Server-Zertifikat

Last modified by Jonas Jelten on 2024/08/23 12:30
From version 2.1
edited by Leo Fahrbach
on 2023/05/19 14:46
Change comment: There is no comment for this version
To version 4.1
edited by Jonas Jelten
on 2023/05/25 12:47
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.fahrbach
1 +XWiki.jelten
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,19 +16,18 @@
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 -{{html wiki="true"}}
24 -{{code}}# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
23 +```
24 +# 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 -{{/code}}
31 -{{/html}}
30 +```
32 32  
33 33  `rbg-cert.service` und `rbg-cert.timer` **verlängern** das Zertifikat automatisch 30 Tage vor Ablauf.
34 34  
... ... @@ -43,17 +43,14 @@
43 43  
44 44  Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`:
45 45  
46 -{{html wiki="true"}}
47 -{{code}}
45 +```
48 48  SSLCertificateFile /etc/apache2/tls/fullchain.pem
49 49  SSLCertificateKeyFile /etc/apache2/tls/key.pem
50 -{{/code}}
51 -{{/html}}
48 +```
52 52  
53 53  Und der automatische renew-hook (`chmod +x` nicht vergessen!)
54 54  
55 -{{html wiki="true"}}
56 -{{code}}
52 +```
57 57  $ cat /usr/local/cert.d/apache2
58 58  #!/bin/bash
59 59  set -o nounset
... ... @@ -67,13 +67,12 @@
67 67  install --mode 0644 "$1".fullchain.pem /etc/apache2/tls/fullchain.pem
68 68  
69 69  systemctl reload apache2.service
70 -{{/code}}
71 -{{/html}}
66 +```
72 72  
73 73  ### Beispiel für nginx
74 74  
75 -{{html wiki="true"}}
76 -{{code}}$ cat /etc/nginx/conf.d/ssl.conf
70 +```
71 +$ cat /etc/nginx/conf.d/ssl.conf
77 77  # config from https://mozilla.github.io/server-side-tls/ssl-config-generator/
78 78  
79 79  ssl_certificate /etc/nginx/tls/fullchain.pem; # cert + parent CAs except root CA
... ... @@ -95,13 +95,11 @@
95 95  
96 96  add_header X-XSS-Protection "1; mode=block";
97 97  add_header X-Content-Type-Options nosniff;
98 -{{/code}}
99 -{{/html}}
93 +```
100 100  
101 101  Und der renew-hook (`chmod +x` nicht vergessen!)
102 102  
103 -{{html wiki="true"}}
104 -{{code}}
97 +```
105 105  $ cat /usr/local/cert.d/nginx
106 106  #!/bin/bash
107 107  set -o nounset
... ... @@ -115,13 +115,12 @@
115 115  install --mode 0644 "$1".fullchain.pem /etc/nginx/tls/fullchain.pem
116 116  
117 117  systemctl reload nginx.service
118 -{{/code}}
119 -{{/html}}
111 +```
120 120  
121 121  ### Allgemeines Beispiel
122 122  
123 -{{html wiki="true"}}
124 -{{code}}$ cat /usr/local/cert.d/yourservice
115 +```
116 +$ cat /usr/local/cert.d/yourservice
125 125  #!/bin/bash
126 126  set -o nounset
127 127  set -o errexit
... ... @@ -132,8 +132,7 @@
132 132  #install --mode 0644 --owner myowner "$1".chain.pem /etc/mydaemon/tls/chain.pem
133 133  #install --mode 0644 --owner myowner "$1".fullchain.pem /etc/mydaemon/tls/chainwithcert.pem
134 134  #systemctl reload mydaemon
135 -{{/code}}
136 -{{/html}}
127 +```
137 137  
138 138  ## Serverzertifikat für alle anderen Maschinen, deren Namen über die Strukturdb verwaltet werden
139 139  
... ... @@ -146,8 +146,8 @@
146 146  Das Programm `rbg-cert` verwendet auch die API, d.h. man kann es auf andere Maschinen portieren.
147 147  Zur Vorbereitung auf den Einsatz von rbg-cert sind folgende Schritte notwendig:
148 148  
149 -{{html wiki="true"}}
150 -{{code}}echo $UQN > /etc/uqn
140 +```
141 +echo $UQN > /etc/uqn
151 151  apt install strongswan-pki
152 152  apt install python3-cryptography
153 153  
... ... @@ -160,8 +160,7 @@
160 160  
161 161  pki --pub --in $UQN.privkey.pem --outform pem > $UQN.pubkey.pem
162 162  # Diesen pubkey dann in der StrukturDB für PIRA registrieren
163 -{{/code}}
164 -{{/html}}
154 +```
165 165  
166 166  `rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
167 167  
... ... @@ -175,13 +175,12 @@
175 175  
176 176  Production:
177 177  
178 -{{html wiki="true"}}
179 -{{code}}URL: https://pira.in.tum.de/v0/server/[UQN]
168 +```
169 +URL: https://pira.in.tum.de/v0/server/[UQN]
180 180  
181 - GET → {cert, chain, fullchain, names, should_renew}
171 + GET → {cert, chain, fullchain, names, should_renew}
182 182   POST {csr}
183 -{{/code}}
184 -{{/html}}
173 +```
185 185  
186 186  Hier sind keine Tests zulässig.
187 187  
... ... @@ -191,13 +191,13 @@
191 191  
192 192  Manuelle Ausstellung mit Genehmigung durch RBG nur möglich, wenn technisch weder rbg-cert noch Let's Encrypt möglich sind:
193 193  
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)"
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' -addext "subjectAltName = DNS:OTHERNAME.cit.tum.de, DNS:ANOTHERNAME.cit.tum.de"`
186 +1. [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN):
187 + 1. `.csr` hochladen
188 + 1. unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
189 + 1. alle anderen Felder leer lassen
190 +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.
191 +1. auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen
192 +1. [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)"