19.06.2025

2080

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

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: 18.07.2025 um 20:07 Uhr

16 Kommentare

Neuester Kommentar

Moin,

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.

---

🔍 Problem 1: `VERIFY nsCertType ERROR: CN=Name, require nsCertType=SERVER`

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.

---

✅ Lösung für EasyRSA 3.x (modern):

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.

---

Alternative: Upgrade auf OpenVPN ≥2.4.x

OpenVPN ab Version 2.4 akzeptiert `extendedKeyUsage` und benötigt `nsCertType` nicht mehr.
Empfehlung: Update durchführen, wenn möglich – auch aus Sicherheitsgründen.

---

🔍 Problem 2: Fehler mit `.rnd` in EasyRSA 2.x (2014)

Der Fehler:

`
Can't load ...easy-rsa/.rnd into RNG
RAND_load_file:Cannot open file
`

✅ Lösung:

Die `.rnd`-Datei wird vom alten `openssl.exe` erwartet, existiert aber nicht. Erstelle sie manuell:

Variante 1 – über PowerShell:

`powershell
cd "C:\Program Files\OpenVPN\easy-rsa"
[System.IO.File]::WriteAllBytes(".rnd", (1..1024 | ForEach-Object {Get-Random -Maximum 256}))
`

Variante 2 – mit OpenSSL direkt:

`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.

---

🔄 Empfehlung (sicher und nachhaltig):

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).

@xaero1891

Danke für die Info. Könnte zum Ziel führen. Unklar ist mir noch
`bash
easyrsa --subject-alt-name="..." build-server-full server1 nopass
`
Genauer gasagt ="..." Einfach nur drei Punke oder gehört da was hin?

Sorry, ich habe jetzt 7 Stunden dran gehangen und bin etwas "weich" in der Birne.

Hallo,

Zitat von @flicflac2025:
Ich habe vor 10 Jahren einen openvpn Server

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.

Hast Du in Deiner Client Config die Line

verify-x509-name "xxxx"  name

Wenn ja anpassen auf neuen Namen, oder rausnehmen.

@peter

Im Jahr 2015 hattest du schon MS Server 2019?>

Lief erst auf Win10 Pro und wurde dann auf den MSS2019 kopiert.

Erst? Als Datenspeicher nutzt du noch Tonrollen?>

3650 Tage war damals Standard. Und wenn es läuft...
Ich habe hier 3650 Sklaven welche es in Tontafeln ritzen.

Fehlermeldungen Lesen, und Verstehen. Notfalls hilft dir heutzutage eine Suchmaschine deines Vertrauens.>

In den Suchmaschinen meines Vertrauens findet man oft genau solch helfende und aussagekräftige Hinweise.

@aqui
Bei den Konfig-Dateien gebe ich dir recht, einfach ein Ruf der Verzweiflung.

@all
Der VPN Server soll zeitnah vom MS-Server verschwinden und von einem Router übernommen werden. Angedacht ist DrayTek Vigor2927. Für alternative Vorschläge bin ich offen, sollte aber openvpn unterstützen und 50 (25) gleichzeitige VPN-Verbindungen unterstützen, unter der 3000 EUR Klasse

.
Im Moment muss ich das VPN schnellstens wieder zum Laufen bringen. Bei der Einrichtung vor 10 Jahren hatte ich eine super Anleitung mit guter Erläuterung. Leider verschwunden

Danke erstmal für eure Unterstützung.

Schönen Abend noch
Gruß flic

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

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.

@commodity
Nach der Beschreibung (1. Link) habe ich es gemacht.
Der Tipp mit dem dedizieten VPN-Gateway ist gar nicht so schlecht. OPNsense schaue ich mir mal an, schlimmer als die Konfiguration des jetzigen Bintec-Router (Digitalisierungsbox Telekom) kanns kaum sein.

@aqui
Die verlinkte Anleitung hab eich mal überflogen. Da finde ich bestimmt noch einige Infos welche das Leben leichter machen.

@all
Der Hinweis von @xaero1891 mit `nsCertType = server` hat zum Erfolg geführt. Die VPN-Verbindung läuft wieder. Nun muss ich die Client-Dateien nur noch an die x Notebooks verteilen...

Besten Dank nochmal an alle.

Gruß flic

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:

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