[strongSwan] Self signed ca cert fails policy check

[Andreas Fett]

Hi,

I recently switched from the strongswan package from
debian stable (4.4.1) to a more recent version from
debian backports (4.5.2).

After the switch pubkey authentifikation stopped working.

Apr 20 15:51:41 ipsec charon: 01[NET] received packet: from x.x.x.x[4500] to y.y.y.y[4500]
Apr 20 15:51:41 ipsec charon: 01[ENC] parsed IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH CP(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) +N(NO_ADD_ADDR) N(MULT_AUTH) N((40960)) ]
Apr 20 15:51:41 ipsec charon: 01[IKE] received cert request for "CN=CA, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[IKE] received end entity cert "CN=user, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG] looking for peer configs matching y.y.y.y[ipsec at example.de]...x.x.x.x[user at example.de]
Apr 20 15:51:41 ipsec charon: 01[CFG] selected peer config 'ikv2-boxen' Apr 20 15:51:41 ipsec charon: 01[CFG]   using certificate "CN=user, ...  C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG]   using trusted ca certificate "CN=CA, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG] checking certificate status of "CN=user, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG]   using trusted certificate "CN=CA, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG]   crl correctly signed by "CN=CA, ... C=DE"
Apr 20 15:51:41 ipsec charon: 01[CFG]   crl is valid: until May 20 15:49:56 2012
Apr 20 15:51:41 ipsec charon: 01[CFG]   using cached crl
Apr 20 15:51:41 ipsec charon: 01[CFG] certificate status is good
Apr 20 15:51:41 ipsec charon: 01[CFG] policy 1.1.1.1.1 missing in issuing certificate 'CN=CA, ... C=DE'
Apr 20 15:51:41 ipsec charon: 01[IKE] no trusted RSA public key found for 'user at example.de'
Apr 20 15:51:41 ipsec charon: 01[IKE] peer supports MOBIKE
Apr 20 15:51:41 ipsec charon: 01[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

After disabling the constraint plugin:

... like above ...

Apr 20 18:23:12 ipsec charon: 13[CFG] certificate status is good
Apr 20 18:23:12 ipsec charon: 13[CFG]   reached self-signed root ca with a path length of 0
Apr 20 18:23:12 ipsec charon: 13[IKE] authentication of 'user at example.de' with RSA signature successful
Apr 20 18:23:12 ipsec charon: 13[IKE] peer supports MOBIKE
Apr 20 18:23:12 ipsec charon: 13[IKE] authentication of 'ipsec at example.de' (myself) with RSA signature successful
Apr 20 18:23:12 ipsec charon: 13[IKE] IKE_SA ikv2-boxen[2] established between y.y.y.y[ipsec at example.de]...x.x.x.x[user at example.de]

Unfortunatly I do not understand the following log output:
policy 1.1.1.1.1 missing in issuing certificate 'CN=CA, ... C=DE'

I suspect it has something to do with X509v3 extensions, namely X509v3 constraints.

Our ca certs extension section looks like this:

X509v3 extensions:
    X509v3 Subject Key Identifier:
        XX:XX:XX
    X509v3 Authority Key Identifier:
        keyid:XX:XX:XXX
        DirName:/CN=CA/O=..../C=DE
        serial:XX:XX:XX

    X509v3 Basic Constraints:
        CA:TRUE

While the ca cert used in the strongswan test suits look like this:
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:TRUE, pathlen:1
    X509v3 Key Usage:
        Certificate Sign, CRL Sign
    X509v3 Subject Key Identifier:
        5D:A7:DD:70:06:51:32:7E:E7:B6:6D:B3:B5:E5:E0:60:EA:2E:4D:EF
    X509v3 Authority Key Identifier:
        keyid:5D:A7:DD:70:06:51:32:7E:E7:B6:6D:B3:B5:E5:E0:60:EA:2E:4D:EF
        DirName:/C=CH/O=Linux strongSwan/CN=strongSwan Root CA
        serial:00

So my questions are:
Do I guess correctly, that it is the constraint plugin which leads to
authentification failure?
If so, wich are the required cert attributes to pass the default (ie. no
extra config) checks?
Is there any (if so which) harm in disabling the constraints plugin?

Regards
Andreas

-- 
The three chief virtues of a programmer are:
Laziness, Impatience and Hubris. -- Larry Wall