Strongswan

Einige Distributionen haben auf das als eierlegende Wollmilchsau beschriebene und von anderen mehr als gehasste systemd umgestellt. Ein Service, der den Startprozess einfacher, paralleler und konfigurierbarer machen soll. In der mitgelieferten Konfiguration von systemd funktioniert auch alles erst mal nach einer frischen Installation, allerdings ist entsprechend der am meisten eingesetzten Konfigurationen vorgegeben, in welcher Reihenfolge was gestartet wird.

Beispiel NFS und Strongswan

Die Entwickler haben sich gedacht, dass wohl in den meisten Konfigurationen erst mal NFS gemounted werden muss und erst dann IPSEC bzw. Strongswan gestartet werden kann, denn es könnte ja sein, dass z.B. /usr ein NFS-Mountpoint ist, aus dem Strongswan erst nach dem Mounten seine Dateien laden könnte. Soweit so gut.

Seit pfSense 2.0 ist ein Zertifikatmanager in die Weboberfläche integriert, mit dem sich Zertifikate, z.B. für IPSEC, erzeugen und signieren lassen.

Bei der Verwendung der mit pfSense erstellten Zertifikate in Strongswan in Versionen kleiner als 4.6.2 kann der private Key nicht geladen werden. Folgende Fehlermeldung erscheint:

charon: 00[LIB] L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 8 builders

Ursache ist, dass Strongswan bis Version 4.6.2 nur private Keys im PKCS#1-Format lesen kann. Die aus pfSense exportierten privaten Keys liegen aber im PKCS#8-Format vor.