Änderungen von Dokument Server-Zertifikat

Zusammenfassung

• Seiteneigenschaften (2 geändert, 0 hinzugefügt, 0 gelöscht)

Details

Seiteneigenschaften

Dokument-Autor

...	...	@@ -1,1 +1,1 @@
1		-XWiki.fahrbach
	1	+XWiki.erbesdob

Inhalt

...	...	@@ -2,7 +2,8 @@
2	2
3	3	Es werden verschiedene Fälle unterschieden:
4	4
5		-* cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]]
	5	+cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]]
	6	+
6	6	* 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"]]
7	7	* andere Domains: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions)
8	8	* 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,10 +12,10 @@
12	12
13	13	Für neue VMs ist die erforderliche Software bereits vorinstalliert.
14	14
15		-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.
16		-1. Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen
17		-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.
18		-1. Nun kann man mit `rbg-cert` Zertifikate beantragen:
	16	+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.
	17	+1 Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen
	18	+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.
	19	+1 Nun kann man mit `rbg-cert` Zertifikate beantragen:
19	19
20	20	```
21	21	# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
...	...	@@ -39,8 +39,10 @@
39	39
40	40	Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`:
41	41
42		- SSLCertificateFile /etc/apache2/tls/fullchain.pem
43		- SSLCertificateKeyFile /etc/apache2/tls/key.pem
	43	+```
	44	+SSLCertificateFile /etc/apache2/tls/fullchain.pem
	45	+SSLCertificateKeyFile /etc/apache2/tls/key.pem
	46	+```
44	44
45	45	Und der automatische renew-hook (`chmod +x` nicht vergessen!)
46	46
...	...	@@ -145,7 +145,7 @@
145	145	# Falls RSA benötigt wird: pki --gen --type rsa --size 3072 --outform pem > $UQN.privkey.pem
146	146
147	147	pki --pub --in $UQN.privkey.pem --outform pem > $UQN.pubkey.pem
148		-# Diesen pubkey dann in der StrukturDB für PIRA registrieren
	151	+# Diesen pubkey dann in der StrukturDB für PIRA registrieren
149	149	```
150	150
151	151	`rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
...	...	@@ -160,11 +160,13 @@
160	160
161	161	Production:
162	162
163		- URL: https://pira.in.tum.de/v0/server/[UQN]
164		-
165		- GET → {cert, chain, fullchain, names, should_renew}
166		- POST {csr}
	166	+```
	167	+URL: https://pira.in.tum.de/v0/server/[UQN]
167	167
	169	+ GET → {cert, chain, fullchain, names, should_renew}
	170	+ POST {csr}
	171	+```
	172	+
168	168	Hier sind keine Tests zulässig.
169	169
170	170	Public keys können im Moment nicht aus der RA entfernt werden, bei Kompromittierung bitte den public key ersetzen.
...	...	@@ -174,11 +174,13 @@
174	174	Manuelle Ausstellung mit Genehmigung durch RBG nur möglich, wenn technisch weder rbg-cert noch Let's Encrypt möglich sind:
175	175
176	176	1. Auf dem Zielserver z.B. nach `/etc/ssl/private`
177		-1. Certificate Signing Request (`csr`) erzeugen`openssl req -newkey rsa:3072 -nodes -keyout SERVERNAME.key -out SERVERNAME.csr -subj '/C=DE/O=Technische Universitaet Muenchen/CN=SERVERNAME.cit.tum.de'`Weitere namen in csr packen: `-addext "subjectAltName = DNS:OTHERNAME.cit.tum.de, DNS:ANOTHERNAME.cit.tum.de"`
	182	+1. Certificate Signing Request (`csr`) erzeugen
	183	+`openssl req -newkey rsa:3072 -nodes -keyout SERVERNAME.key -out SERVERNAME.csr -subj '/C=DE/O=Technische Universitaet Muenchen/CN=SERVERNAME.cit.tum.de'`
	184	+ - weitere namen in csr packen: `-addext "subjectAltName = DNS:OTHERNAME.cit.tum.de, DNS:ANOTHERNAME.cit.tum.de"`
178	178	1. [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN):
179	179	1. `.csr` hochladen
180	180	1. unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
181	181	1. alle anderen Felder leer lassen
182		-1. Bitte den `commonName` (CN) mit Begründung warum rbg-cert und Let's Encrypt nicht möglich sind per E-Mail an [support@ito.cit.tum.de](support@ito.cit.tum.de) schicken.
	189	+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.
183	183	1. auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen
184	184	1. [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)"