Um ein paar seltsame Ideen auszuräumen:
die bisherige TinyCA bat die Funktion, bei der Erstellung eines Zertifikates das Zertifikat mit einem Passwort zu versehen, welches man beim Importieren angeben musste.
Nochmals: ein Zertifikat hat NIE ein Passwort, es gibt immer nur den privaten Schlüssel, der ein Passwort hat. Bei deinem bisherigen Format (pkcs12) ist lediglich der Schlüssel in der gleichen Datei wie das Zertifikat als Paket gespeichert. Das ändert aber nichts an der Aussage.
Wir wollen aber keine OpenVPN Zertifikate benutzen. Es sollen reine ipsec Verbindungen sein.
Es gibt keine "OpenVPN" Zertifikate. Es gibt lediglich TLS/SSL Zertifikate nach x.509 (https://de.wikipedia.org/wiki/X.509).
Dass diese Zertifikate heute für relativ viele Einsatzgebiete genutzt werden, ändert nichts daran, dass im Grundprinzip als Datei betrachtet alles das Gleiche ist. Ob das nun ein Zertifikat für einen Webserver, IPSec, OpenVPN etc. ist, spielt dabei keine Rolle. Lediglich wird für manche das gelieferte Format eine Rolle spielen (.pem, .p12, etc. -> https://de.wikipedia.org/wiki/X.509#Dateinamenserweiterungen_f.C3.BCr_Zertifikate)
Das Einzige, was tatsächlich Zertifikate unterschiedlich macht, sind die gesetzten Flags, was es für ein Zertifikat ist (CA, Server, Client). Aber auch hier ist es lediglich diesen Bits geschuldet, für was das Zert genutzt werden kann. Alles andere ist völlig gleich.
Ich weiß jetzt nicht WOFÜR es bei deinem Einsatzgebiet ein nochmals mit Passwort geschützter Key sein muss, kenne aber selbst KEINE VPN Appliance, die unbedingt für IPSEC ein Zertifikat mit passwortgeschütztem Key benötigt. Es würde auch keinen Sinn machen, denn die Anwendung/Appliance müsste jedes Mal beim Neustart o.ä. den Key neu in den Speicher laden, dabei entschlüsseln etc. und dabei ist im Normalfall kein User anwesend, der den eintippen kann. Somit würde man das Passwort auf dem gleichen Device hinterlegen, was den Key an der Stelle wieder vollkommen unnütz macht. Deshalb werden u.a. auch bspw. Webserver nicht mit einem TLS Key/Zert gesichert, der noch ein Passwort hat, da ansonsten bei jedem Webserver Neustart der Key eingegeben werden müsste. Und wenn nicht, müsste der Key im Klartext auf der Maschine vorhanden sein was wieder das Passwort als 2. Faktor unnütz macht.
Deshalb als Denkanstoß einfach mal nachsehen, OB das überhaupt sein muss oder ob es einfach nur "bisher so war". Es ist ansonsten auch kein Problem, wie schon geschrieben, dem Schlüssel im Nachhinein ein Passwort zu verpassen, für die meisten Einsatzgebiete aber einfach unnötig. Wenn es nur um den sicheren Transfer des Schlüssels geht, ist ein PW geschütztes ZIP wie Virago meint garantiert ebenso sicher. Und einmal eingespielt in der Anwendung, Appliance oder dem Keystore wird der Schlüssel in den allermeisten Fällen eh nie wieder genutzt.
Grüße