Änderungen von Dokument Server-Zertifikat

Zuletzt geändert von Jonas Jelten am 2024/08/23 12:30

Von 1.3 nach 1.4 Von 4.1 nach 5.1

Von Version 1.4

bearbeitet von Leo Fahrbach
am 2023/05/19 14:46

Änderungskommentar: To Markdown

Auf Version 4.1

bearbeitet von Jonas Jelten
am 2023/05/25 12:47

Änderungskommentar: Es gibt keinen Kommentar für diese Version

Rohform
Im Layout

Zusammenfassung

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

Details

Seiteneigenschaften

Dokument-Autor

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

Inhalt

@@ -4,7 +4,7 @@
  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 [[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)
@@ -16,19 +16,18 @@
  Für neue VMs ist die erforderliche Software bereits vorinstalliert.
 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 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:
--{{html wiki="true"}}
--{{code}}# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
++```
++# Zur Kontrolle die konfigurierten Namen abfragen, fehlende in der StrukturDB eintragen!
  rbg-cert --show
--# Initiale Beantragung oder nach Namens&#228;nderung neues Zertifikat beantragen:
++# Initiale Beantragung oder nach Namensänderung neues Zertifikat beantragen:
  rbg-cert --force-request
--# Nach ein paar Minuten das Zertifikat downloaden (oder man wartet bis der systemd-timer l&#228;uft):
++# Nach ein paar Minuten das Zertifikat downloaden (oder man wartet bis der systemd-timer läuft):
  rbg-cert
--{{/code}}
--{{/html}}
++```
  `rbg-cert.service` und `rbg-cert.timer` **verlängern** das Zertifikat automatisch 30 Tage vor Ablauf.
@@ -43,17 +43,14 @@
  Im `VirtualHost` Block in `/etc/apache2/sites-enabled/MYSERVICE.conf`:
--{{html wiki="true"}}
--{{code}}
++```
  SSLCertificateFile /etc/apache2/tls/fullchain.pem
  SSLCertificateKeyFile /etc/apache2/tls/key.pem
--{{/code}}
--{{/html}}
++```
  Und der automatische renew-hook (`chmod +x` nicht vergessen!)
--{{html wiki="true"}}
--{{code}}
++```
  $ cat /usr/local/cert.d/apache2
  #!/bin/bash
  set -o nounset
@@ -67,13 +67,12 @@
  install --mode 0644 "$1".fullchain.pem /etc/apache2/tls/fullchain.pem
  systemctl reload apache2.service
--{{/code}}
--{{/html}}
++```
  ### Beispiel für nginx
--{{html wiki="true"}}
--{{code}}$ cat /etc/nginx/conf.d/ssl.conf
++```
++$ cat /etc/nginx/conf.d/ssl.conf
  # config from https://mozilla.github.io/server-side-tls/ssl-config-generator/
  ssl_certificate /etc/nginx/tls/fullchain.pem;  # cert + parent CAs except root CA
@@ -95,13 +95,11 @@
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Content-Type-Options nosniff;
--{{/code}}
--{{/html}}
++```
  Und der renew-hook (`chmod +x` nicht vergessen!)
--{{html wiki="true"}}
--{{code}}
++```
  $ cat /usr/local/cert.d/nginx
  #!/bin/bash
  set -o nounset
@@ -115,13 +115,12 @@
  install --mode 0644 "$1".fullchain.pem /etc/nginx/tls/fullchain.pem
  systemctl reload nginx.service
--{{/code}}
--{{/html}}
++```
  ### Allgemeines Beispiel
--{{html wiki="true"}}
--{{code}}$ cat /usr/local/cert.d/yourservice
++```
++$ cat /usr/local/cert.d/yourservice
  #!/bin/bash
  set -o nounset
  set -o errexit
@@ -132,8 +132,7 @@
  #install --mode 0644 --owner myowner "$1".chain.pem /etc/mydaemon/tls/chain.pem
  #install --mode 0644 --owner myowner "$1".fullchain.pem /etc/mydaemon/tls/chainwithcert.pem
  #systemctl reload mydaemon
--{{/code}}
--{{/html}}
++```
  ## Serverzertifikat für alle anderen Maschinen, deren Namen über die Strukturdb verwaltet werden
@@ -146,8 +146,8 @@
  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:
--{{html wiki="true"}}
--{{code}}echo $UQN > /etc/uqn
++```
++echo $UQN > /etc/uqn
  apt install strongswan-pki
  apt install python3-cryptography
@@ -160,8 +160,7 @@
  pki --pub --in $UQN.privkey.pem --outform pem > $UQN.pubkey.pem
  # Diesen pubkey dann in der StrukturDB f&#252;r PIRA registrieren
--{{/code}}
--{{/html}}
++```
  `rbg-cert` und systemd timer/service sind von einer aktuellen Ubuntu-VM zu kopieren.
@@ -175,13 +175,12 @@
  Production:
--{{html wiki="true"}}
--{{code}}URL: https://pira.in.tum.de/v0/server/[UQN]
++```
++URL: https://pira.in.tum.de/v0/server/[UQN]
--  GET &#8594; {cert, chain, fullchain, names, should_renew}
++  GET → {cert, chain, fullchain, names, should_renew}
    POST {csr}
--{{/code}}
--{{/html}}
++```
  Hier sind keine Tests zulässig.
@@ -191,13 +191,13 @@
  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` wechseln
--   1 Certificate Signing Request (`csr`) erzeugen
--
--   1 [Bei der CA](https://cert-manager.com/customer/DFN/ssl/dUIh9O1QABKy40PikBgN):
--      1 `.csr` hochladen
--      1 unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
--      1 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 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)"
++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' -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. `.csr` hochladen
++    1. unter "Subject Alternative Names" alle weiteren ggf. benötigten Namen eintragen
++    1. 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 <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)"

Änderungen von Dokument Server-Zertifikat

Zusammenfassung

Details

Navigation