Änderungen von Dokument Server-Zertifikat

Zuletzt geändert von Jonas Jelten am 2024/08/23 12:30
Von Version 1.4
bearbeitet von Leo Fahrbach
am 2023/05/19 14:46
Änderungskommentar: To Markdown
Auf Version 1.3
bearbeitet von wikibot
am 2023/02/13 19:51
Änderungskommentar: langfix

Zusammenfassung

Details

Seiteneigenschaften
Dokument-Autor
... ... @@ -1,1 +1,1 @@
1 -XWiki.fahrbach
1 +XWiki.wikibot
Syntax
... ... @@ -1,1 +1,1 @@
1 -Markdown 1.2
1 +XWiki 2.1
Inhalt
... ... @@ -1,25 +1,29 @@
1 +
2 +
1 1  {{toc/}}
2 2  
3 -# Server-Zertifikate
4 4  
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 += Server-Zertifikate =
8 8  
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 -* andere Domains: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions)
11 -* Falls keine der Optionen möglich ist: Es muss begründet werden, warum weder rbg-cert noch Let's Encrypt möglich ist, dann kann ausnahmsweise eine [[manuelle Ausstellung|Informatik.Benutzerwiki.ServerZertifikate|anchor="Sonderfall_manuelle_Ausstellung"]] erfolgen.
12 -* Hilfe, ich habe EC Schlüssel und muss aber in die Vergangenheit zu RSA reisen: [[Neuen Schlüssel generieren und in der Struk eintragen|Informatik.Benutzerwiki.ServerZertifikate|anchor="Vorbereitung_bei_Nutzung_von_rbg_45cert"]]
9 +Es werden verschiedene Fälle unterschieden:
13 13  
14 -## Ubuntu VM
11 + cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert>>Informatik.Benutzerwiki.ServerZertifikate||anchor="Ubuntu_VM"]]
12 +* 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"]]
13 +* andere Domains: eigenständig mit [[Let's Encrypt>>https://certbot.eff.org/instructions]]
14 +* Falls keine der Optionen möglich ist: Es muss begründet werden, warum weder rbg-cert noch Let's Encrypt möglich ist, dann kann ausnahmsweise eine [[manuelle Ausstellung>>Informatik.Benutzerwiki.ServerZertifikate||anchor="Sonderfall_manuelle_Ausstellung"]] erfolgen.
15 +* Hilfe, ich habe EC Schlüssel und muss aber in die Vergangenheit zu RSA reisen: [[Neuen Schlüssel generieren und in der Struk eintragen>>Informatik.Benutzerwiki.ServerZertifikate||anchor="Vorbereitung_bei_Nutzung_von_rbg_45cert"]]
15 15  
17 +== Ubuntu VM ==
18 +
16 16  Für neue VMs ist die erforderliche Software bereits vorinstalliert.
17 17  
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:
21 +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.
22 + 1 Das Zertifikat wird dann in ##/var/lib/rbg-cert/live/HOST.cert.pem## liegen
23 + 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.
24 + 1 Nun kann man mit ##rbg-cert## Zertifikate beantragen:
22 22  
26 +
23 23  {{html wiki="true"}}
24 24  {{code}}# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
25 25  rbg-cert --show
... ... @@ -30,19 +30,22 @@
30 30  {{/code}}
31 31  {{/html}}
32 32  
33 -`rbg-cert.service` und `rbg-cert.timer` **verlängern** das Zertifikat automatisch 30 Tage vor Ablauf.
34 34  
38 +
39 +##rbg-cert.service## und ##rbg-cert.timer## **verlängern** das Zertifikat automatisch 30 Tage vor Ablauf.
40 +
35 35  Bitte modifiziert unsere Software nicht, denn sie wird zentral von uns aktualisiert. Bei Fragen/Anregungen gerne die Systemgruppe kontaktieren.
36 36  
37 -### Beispiel-Script für server reload
43 +=== Beispiel-Script für server reload ===
38 38  
39 -Da Programme (nginx, postfix, ...) nicht riechen können, wann ein neues Zertifikat da ist, muss man ihnen das mitteilen.
40 -Am einfachsten mit Scripten in `/usr/local/cert.d/...`, die ausführbar sind (`chmod +x`):
45 +Da Programme (nginx, postfix, ...) nicht riechen können, wann ein neues Zertifikat da ist, muss man ihnen das mitteilen.
46 +Am einfachsten mit Scripten in ##/usr/local/cert.d/...##, die ausführbar sind (##chmod +x##):
41 41  
42 -### Beispiel für Apache
48 +=== Beispiel für Apache ===
43 43  
44 -Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`:
50 +Im ##VirtualHost## Block in ##/etc/apache2/sites-enabled/MYSERVICE.conf##:
45 45  
52 +
46 46  {{html wiki="true"}}
47 47  {{code}}
48 48  SSLCertificateFile /etc/apache2/tls/fullchain.pem
... ... @@ -50,8 +50,11 @@
50 50  {{/code}}
51 51  {{/html}}
52 52  
53 -Und der automatische renew-hook (`chmod +x` nicht vergessen!)
54 54  
61 +
62 +Und der automatische renew-hook (##chmod +x## nicht vergessen!)
63 +
64 +
55 55  {{html wiki="true"}}
56 56  {{code}}
57 57  $ cat /usr/local/cert.d/apache2
... ... @@ -70,8 +70,11 @@
70 70  {{/code}}
71 71  {{/html}}
72 72  
73 -### Beispiel für nginx
74 74  
84 +
85 +=== Beispiel für nginx ===
86 +
87 +
75 75  {{html wiki="true"}}
76 76  {{code}}$ cat /etc/nginx/conf.d/ssl.conf
77 77  # config from https://mozilla.github.io/server-side-tls/ssl-config-generator/
... ... @@ -98,8 +98,11 @@
98 98  {{/code}}
99 99  {{/html}}
100 100  
101 -Und der renew-hook (`chmod +x` nicht vergessen!)
102 102  
115 +
116 +Und der renew-hook (##chmod +x## nicht vergessen!)
117 +
118 +
103 103  {{html wiki="true"}}
104 104  {{code}}
105 105  $ cat /usr/local/cert.d/nginx
... ... @@ -118,8 +118,11 @@
118 118  {{/code}}
119 119  {{/html}}
120 120  
121 -### Allgemeines Beispiel
122 122  
138 +
139 +=== Allgemeines Beispiel ===
140 +
141 +
123 123  {{html wiki="true"}}
124 124  {{code}}$ cat /usr/local/cert.d/yourservice
125 125  #!/bin/bash
... ... @@ -135,17 +135,21 @@
135 135  {{/code}}
136 136  {{/html}}
137 137  
138 -## Serverzertifikat für alle anderen Maschinen, deren Namen über die Strukturdb verwaltet werden
139 139  
158 +
159 +== Serverzertifikat für alle anderen Maschinen, deren Namen über die Strukturdb verwaltet werden ==
160 +
140 140  Für andere Maschinen können die Zertifikate über API bezogen werden, sofern die Namen alle in der Strukturdb verwaltet werden. Die Namen müssen also ebenfalls wie obenstehend beschrieben in der Strukturdb konfiguriert werden.
141 141  
142 -_Wir bitten, vor der Nutzung die Systemgruppe zur Beratung zu kontaktieren_. Im Lauf der Zeit können API-Änderungen notwendig werden, dies bitte im Hinterkopf behalten.
163 +//Wir bitten, vor der Nutzung die Systemgruppe zur Beratung zu kontaktieren//. Im Lauf der Zeit können API-Änderungen notwendig werden, dies bitte im Hinterkopf behalten.
143 143  
144 -### Vorbereitung bei Nutzung von rbg-cert
165 +=== Vorbereitung bei Nutzung von rbg-cert ===
145 145  
146 -Das Programm `rbg-cert` verwendet auch die API, d.h. man kann es auf andere Maschinen portieren.
167 +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  
170 +
171 +
149 149  {{html wiki="true"}}
150 150  {{code}}echo $UQN > /etc/uqn
151 151  apt install strongswan-pki
... ... @@ -163,18 +163,22 @@
163 163  {{/code}}
164 164  {{/html}}
165 165  
166 -`rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
167 167  
190 +
191 +##rbg-cert## und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
192 +
168 168  Falls Eigenentwicklungen zwingend notwendig sind, bitte das Verhalten von rbg-cert beibehalten!
169 169  
170 -### Enrollment
195 +=== Enrollment ===
171 171  
172 -Der public key wird im Hosteintrag in der StrukturDB gespeichert. Bspw. per struklib auf lsadmin oder per <https://rbgwebapp.in.tum.de/struktur/treeview.> Nach spätestens einer guten Minute sollte der Key dann der RA bekannt sein, ab diesem Zeitpunkt kann die API verwendet werden.
197 +Der public key wird im Hosteintrag in der StrukturDB gespeichert. Bspw. per struklib auf lsadmin oder per https://rbgwebapp.in.tum.de/struktur/treeview. Nach spätestens einer guten Minute sollte der Key dann der RA bekannt sein, ab diesem Zeitpunkt kann die API verwendet werden.
173 173  
174 -### API
199 +=== API ===
175 175  
176 176  Production:
177 177  
203 +
204 +
178 178  {{html wiki="true"}}
179 179  {{code}}URL: https://pira.in.tum.de/v0/server/[UQN]
180 180  
... ... @@ -183,21 +183,25 @@
183 183  {{/code}}
184 184  {{/html}}
185 185  
213 +
214 +
186 186  Hier sind keine Tests zulässig.
187 187  
188 188  Public keys können im Moment nicht aus der RA entfernt werden, bei Kompromittierung bitte den public key ersetzen.
189 189  
190 -## Sonderfall manuelle Ausstellung
219 +== Sonderfall manuelle Ausstellung ==
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)"
223 +1 Auf dem Zielserver z.B. nach ##/etc/ssl/private## wechseln
224 + 1 Certificate Signing Request (##csr##) erzeugen
225 + {{{
226 +openssl req -newkey rsa:3072 -nodes -keyout SERVERNAME.key -out SERVERNAME.csr -subj '/C=DE/O=Technische Universitaet Muenchen/CN=SERVERNAME.cit.tum.de'
227 +}}}
228 + 1 [[Bei der CA>>https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN]]:
229 + 1 ##.csr## hochladen
230 + 1 unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
231 + 1 alle anderen Felder leer lassen
232 + 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.
233 + 1 auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen
234 + 1 [[herunterladen>>https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download]] mit ID und "Certificate (w/issuer after)"