Opennet Techniktreffen CA-Renewal 2023 (26.06.2023)

Wir sind heute auf ein kritisches Problem für das CA Renewal gestoßen.
Unsere Annahme war, dass die OpenVPN Server der alten CA und der neuen CA gleichzeitig vertrauen können. Somit könnten wir die Client-Zertifikate nacheinander austauschen und die VPN Server würden Verbindungen von alten Zertifikaten und neuen Zertifikaten annehmen.
Diese Annahme ist evtl. falsch.
Technisch gibt es das Problem, dass der OpenVPN Server keine CA Zertifikatsketten einliest und akzeptiert, welche mehrere Zertifikate mit gleichem CN?/Hash? haben.

Was haben wir versucht?
Erstelle eine Datei ca.cert, welche 4 Zertifikate beinhaltet: root CA (alt + neu), ugw CA (alt + neu). Starte anschließend den openvpn Server. Der Start resultiert in folgendem Fehler:

Mon Jun 26 20:12:48 2023 Cannot load CA certificate file /etc/openvpn/opennet_ugw_2022_test/ca_2ugw_2root.crt (entry 3 did not validate)
Mon Jun 26 20:12:48 2023 Cannot load CA certificate file /etc/openvpn/opennet_ugw_2022_test/ca_2ugw_2root.crt (entry 4 did not validate)
Mon Jun 26 20:12:48 2023 Cannot load CA certificate file /etc/openvpn/opennet_ugw_2022_test/ca_2ugw_2root.crt (only 2 of 4 entries were valid X509 names)
Mon Jun 26 20:12:48 2023 Exiting due to fatal error

Als Teststellung haben wir auf dem Server gai eine Config erstellt, welche folgendermaßen gestartet werden kann:

root@gai:/etc/openvpn/opennet_ugw_2022_test# /usr/sbin/openvpn --config ../opennet_ugw_2022_test.conf

Unten ist zu sehen, wie sich die alten und neuen CAs unterscheiden (in Seriennummern). CN und der Hash bleibt gleich.

root@test:~/opennet# openssl x509 -in oldroot.pem -noout -serial -hash -subject

serial=D09411CA45BAB5F1
9106e34c
subject=C = DE, ST = Mecklenburg-Vorpommern, O = Opennet Initiative e.V., OU = Opennet CA, CN = opennet-root.ca.on, emailAddress = admin@opennet-initiative.de

root@test:~/opennet# openssl x509 -in newroot.pem -noout -serial -hash -subject

serial=155EC6C0F6B384F8
9106e34c
subject=C = DE, ST = Mecklenburg-Vorpommern, O = Opennet Initiative e.V., OU = Opennet CA, CN = opennet-root.ca.on, emailAddress = admin@opennet-initiative.de

root@test:~/opennet# openssl x509 -in oldsub.pem -noout -serial -hash -subject

serial=9E76CF710F71FEF1
7e8721dd
subject=C = DE, ST = Mecklenburg-Vorpommern, O = Opennet Initiative e.V., OU = Opennet CA, CN = opennet-server.ca.on, emailAddress = admin@opennet-initiative.de

root@test:~/opennet# openssl x509 -in newsub.pem -noout -serial -hash -subject

serial=016CE997D210A21C
7e8721dd
subject=C = DE, ST = Mecklenburg-Vorpommern, O = Opennet Initiative e.V., OU = Opennet CA, CN = opennet-server.ca.on, emailAddress = admin@opennet-initiative.de

Wie geht es nun weiter?
Eine Möglichkeit wäre, komplett neue Zertifikate zu erstellen (root ca + sub ca). Dann können alte und neue CA Dateien zusammengeführt werden, sodass OpenVPN dies akzeptiert.

Lucas versucht im OpenVPN Forum grob unser Szenario darzustellen und tiefgehenderes Wissen zu erlangen.

Weiterhin sind uns Probleme mit dem ersten neu erstellten UGW Zertifikat von AP2.50 aufgefallen. Es scheint so, dass dieses neu ausgestellte Zertifikat noch von der alten root CA abhängt. Eine Verifikation mit neuer root CA und neuer Sub CA schlägt fehlt. Die Verifikation ist aber erfolgreich, sobald die alte root CA in Betracht gezogen wird.

Beispiel für erfolgreiche Verifikation:

openssl verify -verbose -CAfile ca-old-root-old-sub.crt ugw2.50-new.crt
openssl verify -verbose -CAfile ca-old-root-new-sub.crt ugw2.50-new.crt

Beispiel für fehlgeschlagene Verifikation:

openssl verify -verbose -CAfile ca-new-root-new-sub.crt ugw2.50-new.crt
openssl verify -verbose -CAfile ca-new-root-old-sub.crt ugw2.50-new.crt