Changes for page Server-Zertifikat

Last modified by Leo Fahrbach on 2025/08/14 12:51

From 9.1 to 8.1

From version 22.1

edited by Leo Fahrbach
on 2025/08/14 12:51

Change comment: There is no comment for this version

To version 9.1

edited by Thomas Walter Erbesdobler
on 2023/07/06 14:57

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (4 modified, 0 added, 0 removed)

Details

Page properties

Title

@@ -1,1 +1,1 @@
--Server-Zertifikat
++Server-Zertifikate

Parent

...	...	@@ -1,1 +1,0 @@
1		-CIT.ITO.Docs.Services.Certificates.WebHome

Author

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

Content

@@ -2,20 +2,20 @@
  Es werden verschiedene Fälle unterschieden:
--* cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]]
--* 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"]]
--* andere Domains: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions)
--* 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="HSonderfallmanuelleAusstellung"]] erfolgen.
--* 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"]]
++  * cit/in/ma.tum.de Domains auf [[Ubuntu-VM im ESXi: mit rbg-cert|Informatik.Benutzerwiki.ServerZertifikate|anchor="Ubuntu_VM"]]
++  * 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"]]
++  * andere Domains: eigenständig mit [Let's Encrypt](https://certbot.eff.org/instructions)
++  * 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.
++  * 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"]]
  # Ubuntu VM
  Für neue VMs ist die erforderliche Software bereits vorinstalliert.
--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.
--1. Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen
--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.
--1. Nun kann man mit `rbg-cert` Zertifikate beantragen:
++  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.
++  1. Das Zertifikat wird dann in `/var/lib/rbg-cert/live/HOST.cert.pem` liegen
++  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.
++  1. Nun kann man mit `rbg-cert` Zertifikate beantragen:
  ```
  # Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
@@ -39,8 +39,10 @@
  Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`:
--    SSLCertificateFile /etc/apache2/tls/fullchain.pem
--    SSLCertificateKeyFile /etc/apache2/tls/key.pem
++```none
++SSLCertificateFile /etc/apache2/tls/fullchain.pem
++SSLCertificateKeyFile /etc/apache2/tls/key.pem
++```
  Und der automatische renew-hook (`chmod +x` nicht vergessen!)
@@ -132,44 +132,41 @@
  Das Programm `rbg-cert` verwendet auch die API, d.h. man kann es auf andere Maschinen portieren.
  Zur Vorbereitung auf den Einsatz von rbg-cert sind folgende Schritte notwendig:
--    UQN=host:f:YOURHOSTNAME.cit.tum.de
--    echo $UQN > /etc/uqn
--    apt install python3-cryptography
--
--    mkdir -pm755 /usr/local/cert.d/        # for post-renew trigger scripts
--    mkdir -pm700 /var/lib/rbg-cert/live/   # certs will be here
--    cd /var/lib/rbg-cert/live/
--
--    # Private Key erstellen
--    openssl genrsa -out $UQN.privkey.pem 4096
++```
++echo $UQN > /etc/uqn
++apt install strongswan-pki
++apt install python3-cryptography
--    openssl rsa -in $UQN.privkey.pem -pubout
--    # Diesen pubkey dann in der StrukturDB für PIRA registrieren
++mkdir -pm755 /usr/local/cert.d/        # for post-renew trigger scripts
++mkdir -pm700 /var/lib/rbg-cert/live/   # certs will be here
++cd /var/lib/rbg-cert/live/
--`rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
++pki --gen --type ecdsa --size 256 --outform pem > $UQN.privkey.pem
++# Falls RSA benötigt wird: pki --gen --type rsa --size 3072 --outform pem > $UQN.privkey.pem
++pki --pub --in $UQN.privkey.pem --outform pem > $UQN.pubkey.pem
++# Diesen pubkey dann in der StrukturDB für PIRA registrieren
  ```
--scp VMNAME:/usr/local/bin/rbg-cert /usr/local/bin/rbg-cert
--scp VMNAME:/etc/systemd/system/rbg-cert.service /etc/systemd/system/rbg-cert.service
--scp VMNAME:/etc/systemd/system/rbg-cert.timer /etc/systemd/system/rbg-cert.timer
--systemctl enable rbg-cert.timer
--```
++`rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
++
  Falls Eigenentwicklungen zwingend notwendig sind, bitte das Verhalten von rbg-cert beibehalten!
  ## Enrollment
--Der public key wird im Hosteintrag in der StrukturDB gespeichert. Bspw. per struklib auf lsadmin oder per [https://struktur.ito.cit.tum.de/struktur/](https://struktur.ito.cit.tum.de/struktur/).
++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.
  ## API
  Production:
--    URL: https://pira.in.tum.de/v0/server/[UQN]
--
--      GET → {cert, chain, fullchain, names, should_renew}
--      POST {csr}
++```none
++URL: https://pira.in.tum.de/v0/server/[UQN]
++  GET → {cert, chain, fullchain, names, should_renew}
++  POST {csr}
++```
++
  Hier sind keine Tests zulässig.
  Public keys können im Moment nicht aus der RA entfernt werden, bei Kompromittierung bitte den public key ersetzen.
@@ -178,15 +178,14 @@
  Manuelle Ausstellung mit Genehmigung durch RBG nur möglich, wenn technisch weder rbg-cert noch Let's Encrypt möglich sind:
--1. Auf dem Zielserver z.B. nach `/etc/ssl/private`
--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"`
--1. [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN):
++  1. Auf dem Zielserver z.B. nach `/etc/ssl/private`
++  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"`
++  1. [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN):
 . `.csr` hochladen
 . unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
 . alle anderen Felder leer lassen
--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.
--1. auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen
--1. [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)"
++  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.
++  1. auf "Certificate approved" E-Mail warten, "Certificate ID" entnehmen
++  1. [herunterladen](https://cert-manager.com/customer/DFN/idp/ssl/dUIh9O1QABKy40PikBgN?action=download) mit ID und "Certificate (w/issuer after)"

Changes for page Server-Zertifikat

Summary

Details

Navigation