OpenVPN - neue Zertifikate
Hallo
Ich habe vor 10 Jahren einen openvpn Server und einen Client-Zugriff installiert, V2.3.6. Der openvpn-Server läuft auf einem Windows-Server 2019. Nach 10 Jahren sind die Zertifikate abgelaufen.
Ich habe neue Zertifikate erstellt mit Easyrsa 3.0.4. Das generieren war problemlos, aber nach dem Ersetzen der Zertifikate auf Server und Client erhalte ich beim Verbindungsaufbau den Fehler:
VERIFY nsCertType ERROR: CN=Name, require nsCertType=SERVER
Der Versuch mit der damals verwendeten Version von Easyrsa (aus 2014) bringt beim generieren des Client-Key die Fehlermeldung:
Warning: Ignoring -days without -x509; not generating a certificate
Can't load C:\Program Files\OpenVPN\easy-rsa/.rnd into RNG
5C420000:error:12000079:random number generator:RAND_load_file:Cannot open file:crypto\rand\randfile.c:107:Filename=C:\Program Files\OpenVPN\easy-rsa/.rnd
Es wird kein Zertifikat *.crt für den Client erstellt.
Ich suche für beide Möglichkeiten dringend eine Lösung.
Danke
Ich habe vor 10 Jahren einen openvpn Server und einen Client-Zugriff installiert, V2.3.6. Der openvpn-Server läuft auf einem Windows-Server 2019. Nach 10 Jahren sind die Zertifikate abgelaufen.
Ich habe neue Zertifikate erstellt mit Easyrsa 3.0.4. Das generieren war problemlos, aber nach dem Ersetzen der Zertifikate auf Server und Client erhalte ich beim Verbindungsaufbau den Fehler:
VERIFY nsCertType ERROR: CN=Name, require nsCertType=SERVER
Der Versuch mit der damals verwendeten Version von Easyrsa (aus 2014) bringt beim generieren des Client-Key die Fehlermeldung:
Warning: Ignoring -days without -x509; not generating a certificate
Can't load C:\Program Files\OpenVPN\easy-rsa/.rnd into RNG
5C420000:error:12000079:random number generator:RAND_load_file:Cannot open file:crypto\rand\randfile.c:107:Filename=C:\Program Files\OpenVPN\easy-rsa/.rnd
Es wird kein Zertifikat *.crt für den Client erstellt.
Ich suche für beide Möglichkeiten dringend eine Lösung.
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673469
Url: https://administrator.de/forum/openvpn-zertifikate-server-client-673469.html
Ausgedruckt am: 16.07.2025 um 02:07 Uhr
16 Kommentare
Neuester Kommentar
Moin,
ChatGPT sagt:
ChatGPT sagt:
Quelle: ChatGPT KI
Danke für die ausführliche Beschreibung – das Problem ist ein Klassiker bei älteren OpenVPN-Versionen in Kombination mit modernen EasyRSA-Zertifikaten.
---
Dieser Fehler tritt auf, weil:
---
Damit OpenVPN 2.3.6 das Zertifikat akzeptiert, musst du beim Erstellen des Server-Zertifikats dieses Flag setzen:
`bash
easyrsa --subject-alt-name="..." build-server-full server1 nopass
`
Und vorher in der Datei `x509-types/server` (in deinem EasyRSA-Verzeichnis) folgendes hinzufügen:
`text
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
`
---
---
Der Fehler:
`
Can't load ...easy-rsa/.rnd into RNG
RAND_load_file:Cannot open file
`
Die `.rnd`-Datei wird vom alten `openssl.exe` erwartet, existiert aber nicht. Erstelle sie manuell:
`powershell
cd "C:\Program Files\OpenVPN\easy-rsa"
[System.IO.File]::WriteAllBytes(".rnd", (1..1024 | ForEach-Object {Get-Random -Maximum 256}))
`
`cmd
openssl rand -out .rnd -hex 1024
`
Dann kannst du erneut versuchen:
`cmd
build-key client1
`
---
1. OpenVPN auf v2.4.x oder 2.5.x updaten.
2. EasyRSA 3.0.4 beibehalten.
3. `nsCertType = server` temporär ins `x509-types/server` für den Übergang aufnehmen.
4. Auf längere Sicht: NSCertType endgültig auslaufen lassen – modernere Clients/Server benötigen das nicht mehr.
---
Wenn du willst, kann ich dir die passende `vars`-Datei, ein aktualisiertes `x509-types/server`-Profil oder ein genaues Schritt-für-Schritt-Skript liefern – sag einfach, welchen Weg du gehen willst (alt beibehalten oder auf neue Versionen migrieren).
---
Dieser Fehler tritt auf, weil:
- OpenVPN v2.3.6 erwartet noch ein `nsCertType=server`-Attribut im Server-Zertifikat.
- EasyRSA 3.x generiert dieses Feld standardmäßig nicht mehr – es ist veraltet, wurde aber in neueren OpenVPN-Versionen durch `extendedKeyUsage=serverAuth` ersetzt.
---
Damit OpenVPN 2.3.6 das Zertifikat akzeptiert, musst du beim Erstellen des Server-Zertifikats dieses Flag setzen:
`bash
easyrsa --subject-alt-name="..." build-server-full server1 nopass
`
Und vorher in der Datei `x509-types/server` (in deinem EasyRSA-Verzeichnis) folgendes hinzufügen:
`text
- EasyRSA x509-type: server
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
`
Wichtig: `nsCertType = server` muss explizit rein, damit v2.3.6 das akzeptiert.
---
- OpenVPN ab Version 2.4 akzeptiert `extendedKeyUsage` und benötigt `nsCertType` nicht mehr.
- Empfehlung: Update durchführen, wenn möglich – auch aus Sicherheitsgründen.
---
Der Fehler:
`
Can't load ...easy-rsa/.rnd into RNG
RAND_load_file:Cannot open file
`
Die `.rnd`-Datei wird vom alten `openssl.exe` erwartet, existiert aber nicht. Erstelle sie manuell:
`powershell
cd "C:\Program Files\OpenVPN\easy-rsa"
[System.IO.File]::WriteAllBytes(".rnd", (1..1024 | ForEach-Object {Get-Random -Maximum 256}))
`
`cmd
openssl rand -out .rnd -hex 1024
`
Dann kannst du erneut versuchen:
`cmd
build-key client1
`
Achtung: `build-key` braucht `-x509` und `-days` korrekt kombiniert – ggf. via `build-key`-Script aufrufen, nicht direkt mit openssl.
---
1. OpenVPN auf v2.4.x oder 2.5.x updaten.
2. EasyRSA 3.0.4 beibehalten.
3. `nsCertType = server` temporär ins `x509-types/server` für den Übergang aufnehmen.
4. Auf längere Sicht: NSCertType endgültig auslaufen lassen – modernere Clients/Server benötigen das nicht mehr.
---
Wenn du willst, kann ich dir die passende `vars`-Datei, ein aktualisiertes `x509-types/server`-Profil oder ein genaues Schritt-für-Schritt-Skript liefern – sag einfach, welchen Weg du gehen willst (alt beibehalten oder auf neue Versionen migrieren).
Hallo,
Also im Jahr 2015

Gruss,
Peter
Also im Jahr 2015
Der openvpn-Server läuft auf einem Windows-Server 2019.
Im Jahr 2015 hattest du schon MS Server 2019?Nach 10 Jahren sind die Zertifikate abgelaufen.
Erst? Als Datenspeicher nutzt du noch Tonrollen?Ich suche für beide Möglichkeiten dringend eine Lösung.
Fehlermeldungen Lesen, und Verstehen. Notfalls hilft dir heutzutage eine Suchmaschine deines Vertrauens.Der Versuch mit der damals verwendeten Version von Easyrsa (aus 2014) bringt beim generieren des Client-Key die Fehlermeldung:
Manchmal (oft) ändern sich dinge nach (langen) Zeiten. Und 10 Jahre in der IT (wo die IT ca. erst 40 Jahre aufm Buckel hat) ist da schon wie mit 5 Milliarden Jahre im Universum. Gruss,
Peter
ChatGPT sagt:
Dann sollte man es auch entsprechend der Regeln kennzeichnen... Sind KI-Inhalte auf dieser Website erlaubt?
Zeigt übrigens auch Googles KI an wenn man danach sucht...
@flicflac2025
Das hiesige OpenVPN Tutorial hast du gelesen und deine alten Konfig Dateien entsprechend etwas "moderner" angepasst?!
Merkzettel: VPN Installation mit OpenVPN
Ein anonymisiertes Posting deiner (vermutlich) veralteten Konfig Dateien hätte ein zielführendes Troubleshooting vereinfacht.
Nebenbei: Vielleich auch mal drüber nachdenken das etwas angestaubte und wenig performante OpenVPN jetzt gegen etwas Neues und Skalierbareres zu tauschen?! 😉
Gibt ja genug Alternativen:
Merkzettel: VPN Installation mit Wireguard
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
L2TP VPN Server mit preiswerten Mikrotik Routern
Usw. usw.
Ich würde ja nicht im Leben auf die Idee kommen, einen OpenVPN-Server unter Windows zu betreiben.
Vielleicht aber hilft Dir das ein Stück weiter:
internet-xs.de/kb/openvpn-allgemein/openvpn-zertifikate-erstelle ...
Diese Anleitung ist für Linux, sieht vielleicht etwas komisch aus, ist aber perfekt:
ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
Vielleicht kannst Du aus den Erklärungen ein paar Hinweise saugen.
Ich finde es unnötig, OpenVPN auf einen Router zu packen, zumal gerade OpenVPN vergleichsweise Ressourcenhungrig ist (siehe auch den Hinweis des Kollegen @aqui). Schon ein Raspberry Pi hat oft mehr Leistung als der Router und jeder andere Mini-PC tut es noch besser. Den stellt man als VPN-Gateway in ein eigenes Netz und erlaubt von dort aus die Zugriffe ins Produktivnetz. Wenn es der Router sein soll, nimm eine OPNsense, kann man auch fertig kaufen, wenn man es nicht selbst aufspielen mag. Z.B. bei Thomas Krenn, da gibt's auch Beratung.
Viele Grüße, commodity
Vielleicht aber hilft Dir das ein Stück weiter:
internet-xs.de/kb/openvpn-allgemein/openvpn-zertifikate-erstelle ...
Diese Anleitung ist für Linux, sieht vielleicht etwas komisch aus, ist aber perfekt:
ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
Vielleicht kannst Du aus den Erklärungen ein paar Hinweise saugen.
Ich finde es unnötig, OpenVPN auf einen Router zu packen, zumal gerade OpenVPN vergleichsweise Ressourcenhungrig ist (siehe auch den Hinweis des Kollegen @aqui). Schon ein Raspberry Pi hat oft mehr Leistung als der Router und jeder andere Mini-PC tut es noch besser. Den stellt man als VPN-Gateway in ein eigenes Netz und erlaubt von dort aus die Zugriffe ins Produktivnetz. Wenn es der Router sein soll, nimm eine OPNsense, kann man auch fertig kaufen, wenn man es nicht selbst aufspielen mag. Z.B. bei Thomas Krenn, da gibt's auch Beratung.
Viele Grüße, commodity
Bei den Konfig-Dateien gebe ich dir recht
Tipp einfach die klassischen Standard Konfig Dateien aus dem Tutorial ab und passe sie auf deine IP Adressierung an. Dann kommt das auch sofort zum Fliegen. sollte aber openvpn unterstützen
Kollege @commodity hat es oben schon gesagt. OpenVPN ist nicht Multi Threading fähig daher wenig skalierbar und schon etwas in die Jahre gekommen. Das im Enterprise Umfeld weiterzunutzen wäre nicht zukunftsorientiert.Deutlich sinnvoller ist es immer die so oder so auf jedem Hardware Endgerät, egal ob Winblows, Apple Linux oder sämtliche Mobilgeräte, vorhandenen onboard IKEv2 VPN Clients zu verwenden.
Nicht nur das sie sicherer sind, sie sind auch immer optimal ins jeweilige Betriebssystem integriert und damit deutlch besser zentral steuer- und konfigurierbar als (überflüssige) externe VPN Software.
Mit z.B. den Open Source Firewall Klassikern OPNsense oder pfSense auf den üblichen Standard Appliances bist du damit mit entsprechender CPU Hardware für Verschlüsselung (VPN) gerüstet (AES NI) anstatt eines einfachen Plasterouters.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Draytek und z.B. auch NetGear haben einen gravierenden OpenVPN Nachteil das sie ein nicht konfigurierbares NAT im Tunnel erzwingen, was ein transparentes Routing über das VPN unmöglich macht. Das ist leider oft so wenn kommerzielle Router Hersteller Open Source Lösungen zwar bereitstellen aber dann so kastrieren das sie nicht mehr frei konfigurierbar sind und somit einen Vendor Lock provozieren.
Solltest du für die Zukunft also beachten welchen Weg du da gehst.
des jetzigen Bintec-Router
OMG!Der Tipp mit dem dedizieten VPN-Gateway
Ich warte eigentlich noch, dass Kollege @aqui mit mir schimpft. Der will das lieber am Perimeter. Aber im eigenen Netz ist's mindestens genauso sicher, finde ich - und man kann mehr Performance drauf packen.Der Hinweis von @xaero1891
Top, Danke für's Feedback. ChatGPT kann sowas ganz gut.Bitte noch als Lösung markieren.
Und perspektivisch zu WireGuard wechseln, wenn nicht spezifische OpenVPN-Funktionen benötigt werden
Macht das Leben leichter.
Viele Grüße, commodity
Aber im eigenen Netz ist's mindestens genauso sicher, finde ich
Na ja, der große Nachteil ist das man dafür immer ein Loch in die Firewall bohren muss und so ein ungeschütztes Einfallstor erzeugt. Hat immer ein Geschmäckle sowas und ist eher was für Heimnetze und sollte man in einem Enterprise Netz unterlassen. Damit würde man keinen Security Audit überstehen. Letztendlich muss das aber jeder Admin anhand seiner Security Policies immer selbst entscheiden. Nun muss ich die Client-Dateien nur noch an die x Notebooks verteilen...
Mit den onboard VPN Clients wäre das ein simpler GPO Mausklick! Besten Dank nochmal an alle.
Bleibt ja dann nur noch deinen Thread hier dann auch als erledigt zu schliessen!Wie kann ich einen Beitrag als gelöst markieren?
Zitat von @aqui:

Sind KI-Inhalte auf dieser Website erlaubt?
ChatGPT sagt:
Dann sollte man es auch entsprechend der Regeln kennzeichnen... Sind KI-Inhalte auf dieser Website erlaubt?
Erledigt, Cheffe! Kannte ich nicht
Schönes WE!
der große Nachteil ist das man dafür immer ein Loch in die Firewall bohren muss und so ein ungeschütztes Einfallstor erzeugt
Q.e.d. Im Übrigen haben wir den Punkt schon mal ausgiebig diskutiert und der Kollege hatte meine Position am Ende bestätigt. Nochmal knapp:
Dedizierte VPN-Gateways sind im Unternehmensbereich Standardarchitektur. Dann natürlich auch mit DMZ und DDoS/Brute-Force-Absicherung.
Das BSI erwähnt und beschreibt sogar den Aufbau ausdrücklich hier (NET.1.1.A11):
"... Derartige VPN-Gateways SOLLTEN in einer externen DMZ platziert werden. Es
SOLLTE beachtet werden, dass hinreichend gehärtete VPN-Gateways direkt aus dem Internet
erreichbar sein können. Die über das VPN-Gateway authentisierten Zugriffe ins interne Netz MÜSSEN
mindestens die interne Firewall durchlaufen."
Auch das NIST beschreibt dies explizit in NIST SP 800-77 REV. 1:
"The VPN gateway may be a dedicated device that only performs VPN functions, or it
may be part of another network device, such as a firewall or router."
Warum ist das dedizierte Gateway besser? Skalierung, Dienstisolierung, Updateautomatisierung, v.a. Updates unabhängig vom Routerhersteller, verbesserte Logging- und Monitoringmöglichkeiten, Brute-Force-Schutz, stärkere Authentifizierung. Das alles lässt sich auf einer dedizierten Instanz viel besser abbilden.
Der beständig wiederholte Satz mit dem
ein Loch in die Firewall bohren
klingt schön eingängig, ist technisch aber nicht nachvollziehbar. Die Frage ist hier nicht, ob ein Port offen ist, sondern wie er abgesichert ist:Auch die Perimeter-Firewall öffnet ja Ports nach außen, das ist exakt das selbe "Loch". Ein Port ist immer offen. Nur, dass es sich viel verheerender auswirkt, wenn das Firewall-VPN einen Bug hat. Dann führt dieses Loch nämlich u.U. zur Übernahme der Firewall und damit des gesamten Netzes.
Das Netz des VPN-Gateway (DMZ) ist hingegen zusätzlich durch die Firewall abgesichert. Ein Debian- oder Raspberry-Gateway kann man mit automatischen Updates und Fail2Ban ausstatten. Das können viele Router nicht.
Der Schutz einer dedizierten Lösung ist also deutlich höher - wenn man es ordentlich umsetzt. Zugleich sind Leistung und Skalierbarkeit besser.
I.E.: Die Aussage
Damit würde man keinen Security Audit überstehen
ist IMO denkbar unzutreffend und sollte auch, wenn man schon solche Keulen heraus holt, belegt werden.Der Einsatz eines VPN-Gateways will dennoch überlegt werden, denn er ist oft zumindest etwas aufwändiger einzurichten als das VPN am Perimeter-Router. Dafür ist es dann aber auch unabhängig von dessen Betrieb, d.h. wird das Gerät gegen ein anderes System getauscht, muss man, selbst bei Herstellerwechsel, nicht wieder alles neu konfigurieren. Dass insbesondere OpenSource hier langfristig seine Vorteile hat, liegt auf der Hand.
Viele Grüße, commodity
Eine externe DMZ ist aber genau nicht das produktive zu schützende Netz. Das Design was das BSI beschreibt ist natürlich eine sichere Sache, keine Frage. 
Eine externe DMZ ist aber genau nicht das produktive zu schützende Netz
Das ist ja nun hoffentlich jedem klar und deshalb schrieb ich eingangs:... in ein eigenes Netz ...
Nochmals kurz und knapp:
WAN -> Firewall (mit Portfreigabe in die DMZ -> DMZ mit VPN-Gateway -> zurück in die Firewall - > Produktivnetz(e).
In größeren Umgebungen gibt es dann auch noch "innere" Firewalls, aber das brauchen wir im KMU-Umfeld IMO nicht.
Viele Grüße, commodity