Opennet CA/CA Cert Renewal 2023: Unterschied zwischen den Versionen

Version vom 3. Oktober 2023, 21:40 Uhr

Situation

• Sub-CAs laufen Ende 2023/Anfang 2024 ab, siehe Opennet CA und Benutzer:MathiasMahnke/CA Cert Renewal 2013
• wir müssen diese erneuern + alle daraus abgeleiteten Zertifikate
• Entscheidung über CA Parameter - erledigt durch Mathias (mittels xca)
• Sub-CA Resign
• Prüfen, ob abgelaufene OpenVPN Zertifikate überhaupt die Funktion beeinträchtigen
  • ja, laut vertrauenswürdigen Internetquellen ist die Zertifikatsablaufprüfung ein integraler nicht umgehbarer Bestandteil von OpenVPN (https://superuser.com/questions/1521168/how-to-allow-some-expired-client-certificates-in-openvpn)

TODO Liste 2022/2023

Aktueller Prozess - Resign mit vorhandenen Keys:

• (erledigt) CA Zertifikate verlängern
  • (erledigt) Entscheidung: Seriennummern für Root CA übernehmen. Dadurch kann man auf den VPN Servern ein neues Zertifikat einspielen, welches von alten Clients weiterhin vertraut wird.
  • (erledigt) Root CA 15 Jahre verlängert (Ende 2038)
  • (erledigt) alle CAs wurden verlängert (resign) von aktualisierter root CA (private keys sind unverändert)
  • (erledigt) Wiki Seite mit CA Übersicht aktualisieren
  • (erledigt) ca Git aktualisieren
    • einzelne Zertifikate abspeichern, siehe https://github.com/opennet-initiative/ca/tree/main/cert
    • on-bundle erstellen und committen, siehe https://github.com/opennet-initiative/ca/tree/main/web/public)
  • (erledigt) ansible Git aktualisieren
    • update Jahr, siehe https://github.com/opennet-initiative/ansible/commit/4b5e26b64bef21c7e6d9af1b14f9c408e814cc3c
    • update Jahr in Dateinamen, siehe https://github.com/opennet-initiative/ansible/commit/cad74787c18cb39bfc936f50751ec39e18d77c26
  • (erledigt) Testen (bevor auf amano (prod CA Server) eingespielt wird via ansible)
    • VM auf deinem Gerät mit Debian erstellen. Config siehe https://wiki.debian.org/ThomasChung/CloudImage
    • root login erlauben für VM, siehe https://linuxconfig.org/enable-ssh-root-login-on-debian-linux-server
    • ansible Lauf gegen neue VM machen und Rolle 'opennetca' dort anwenden. Jetzt sollte alle neuen CAs hier installiert sein.
    • vom produktiven CA Server (amano) einige CSR Dateien zum Testen kopieren
    • diese CSRs nun signieren, bspw. 'root@localhost:/home/opennetca/ca/vpn-ugw# ./opennetca.sh sign vpn-ugw_2.1.ugw.on_e653cf77'. Natürlich benötigen wir die .key Datei für die Sub-CA hierfür noch.
    • testen, ob Zertifikatskette funktioniert. Beispiel: `root@localhost:/home/opennetca/ca/vpn-ugw# openssl verify -CAfile ../root/opennet-root.ca.on_2022.crt -untrusted opennet-vpn-ugw.ca.on_2022.crt cert/vpn-ugw_2.1.ugw.on_e653cf77.crt

`

• • () Opennet Firmware on-certificates und OpenVPN Pakete aktualisieren

• () auf Opennet CA Server (amano)
  • () CA crt Dateien einspielen
  • () ca-bundle ablegen (neues bundle siehe https://github.com/opennet-initiative/ca/blob/main/web/public/opennet-ca-bundle.tar.gz)
  • () index.txt Rebuild: https://forums.openvpn.net/viewtopic.php?t=9999
  • () config (openssl) Datei anpassen
  • () ca/${ONI_CA_X}/opennetca.cfg anpassen
  • () wenn jetzt neues client crt neu erstellt wird, sollte dieses selbst mit der alten CA funktionieren, weil die private keys der CAs sich nicht geändert haben

• auf Opennet Servern die ca certchain ersetzen mit ansible (hier sollten alle VPN Verbindungen weiter funktionieren weil private Key der CAs unverändert ist)
•  ? service discovery hat damals https genutzt (mit unserer ca) aber wollten wir auf http (unencrypted) umstellen
• jetzt können wir neue Server Zertifikate ausstellen und in Betrieb nehmen
• Firmware Aktualisieren oder alte Firmware mit neuem on-certificates Paket versorgen
• Opennet Server + Client Zertifikate erneuern/austauschen
• einige Opennet User-AP/UGW-AP Zertifikate erneuern/austauschen
• Beginn großflächig Nutzer-APs umstellen
• wir werden den Standardprozess nutzen (neues Zertifikat auf dem AP generieren und dieses dann von neuer CA signieren)
• (erledigt) testen, ob bei alten+neuen Firmware der "Generate" Button für neue Schlüsselerzeugung funktioniert, trotz vorhandem Key
• Idee: Felder vorausfüllen (Emailadresse & co)

Prozedur zum Testen neuer Zertifikate

Voraussetzung:

• SSH Zugriff auf Server gai
• Zugriff auf ein UGW (mit neuem und altem Zertifikat)

Ablauf:

• ssh into Server gai

 cd /etc/openvpn/opennet_ugw_2022_test
 vim ../opennet_ugw_2022_test.conf
 /usr/sbin/openvpn --config ../opennet_ugw_2022_test.conf  # this starts OpenVPN in foreground on port 16999

• ssh into your UGW

 # create config file
 cat > mesh_openvpn_gai_opennet_initiative_de_16999_udp.conf <<EOF
 #!/bin/sh
 remote gai.opennet-initiative.de 16999 udp
 ca /etc/ssl/certs/opennet-initiative.de/opennet-server_bundle.pem  # try new ca bundles here
 remote-cert-tls server
 cd /etc/openvpn/opennet_ugw
 cert on_ugws.crt                                                   # try new ugw cert here
 key on_ugws.key
 client
 nobind
 explicit-exit-notify 1
 persist-tun
 persist-key
 mute-replay-warnings
 dev tap
 dev-type tap
 txqueuelen 1000
 EOF
 
 # start openvpn tunnel via
 openvpn --config mesh_openvpn_gai_opennet_initiative_de_1602_udp.conf

Testfälle

#Test	UGW-Server			UGW-Client			Szenario
	certchain	cert		certchain	cert		
-------------------------------------------------------------------------------------------
1	alt		alt		alt		alt		alles alt, wie bisher
2	neu		neu		alt		alt		nur Server aktualisiert und Clients noch nicht
3	neu		neu		neu		neu		auch UGW aktualisiert

Ergebnis

zu 1) geht
zu 2) geht
zu 3) geht

Liste Cert (zum identifieren in Datei)

Last Chars  CN                      Expire date    Comment
-------------------------------------------------------
7wzA93Y=    opennet-vpn-ugw.ca.on - 2023 	- old
VgUYebE=    opennet-vpn-ugw.ca.on - 2032 	- new  

ziWuGw==    opennet-server.ca.on  - 2024        - old
CTPgmM6y    opennet-server.ca.on  - 2032        - new

TALI5FU=    opennet-root.ca.on    - 2033 	- old
RSWnxw==    opennet-root.ca.on    - 2037 	- cert is defect because of signing problems
DCkOeU0=    opennet-root.ca.on    - 2038 	- new fixed cert
 
IRZ3CMQ==   2.1.ugw.on            - 2025       - old
JWGzI1rI=   2.50.ugw.on           - 2033	- new