On Friday 16 Dec 2011 18:31:01 you wrote: > Le 16/12/2011 18:45, Mick a écrit :
> > Since I cannot change the router firmware, what should I change the
> > 'string_mask = ' on the PC to agree with the router?
>
> My understanding is that string_mask is used when producing an object
> (request or certificate), not when checking its content with the policy
> match directives.
>
> You could either regenerate your CA with string_mask set to "default"
> (which means: first try "PrintableString", then "T61String", then
> "BMPString"). Your router uses PrintableString for pretty much anything
> except commonName, which is encoded in T61String. That could work.
I seem to have overcome the original problem. Now both the cacert and signed
client certificates are formatted in the same way. I used -policy
policy_anything to avoid complaints from openssl ca.
Unfortunately the problem of authenticating on the VPN gateway remains. :-(
I would be grateful for some advice, as I am not sure if I am following the
correct steps. I have created a request for a client certificate:
==========================================
openssl req -config ./openssl_VPN.cnf -new -newkey rsa:2048 -keyout
VPN_test_key.pem -days 1095 -out VPN_test_cert.req
==========================================
Then signed it with the cacert:
==========================================
openssl ca -config ./openssl_VPN.cnf -extensions usr_cert -days 1095 -cert
cacert_VPN.pem -keyfile VPN_CA/private/cakey_VPN.pem -policy policy_anything -
infiles VPN_test_cert.req
Using configuration from ./openssl_VPN.cnf
Enter pass phrase for VPN_CA/private/cakey_VPN.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 3 (0x3)
Validity
Not Before: Dec 26 18:13:18 2011 GMT
Not After : Dec 25 18:13:18 2014 GMT
Subject:
countryName = GB
organizationName = Sundial
commonName = VPN_test_XPS
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
E6:95:82:48:3D:E8:3D:9E:0C:BA:CF:3A:EC:FF:8D:0D:E0:6A:1B:2B
X509v3 Authority Key Identifier:
keyid:CA:91:0A:ED:F9:B5:F4:F7:60:C5:A7:1C:0B:75:94:5C:33:38:F1:AB
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Certificate is to be certified until Dec 25 18:13:18 2014 GMT (1095 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Sundial, CN=Sundial_VPN_CA
Validity
Not Before: Dec 26 18:13:18 2011 GMT
Not After : Dec 25 18:13:18 2014 GMT
Subject: C=GB, O=Sundial, CN=VPN_test_XPS
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:df:d4:74:bc:de:21:bd:61:99:4c:88:97:0a:43:
3f:c0:40:01:73:b8:41:ce:47:46:fd:14:0f:83:6d:
75:54:bc:73:45:f2:99:24:1e:51:f1:d9:b6:8f:9b:
bf:e5:e5:93:00:79:a8:56:38:04:e2:06:69:5a:1e:
29:16:72:25:5e:bb:1a:2d:e0:82:90:b2:46:78:b5:
8d:e7:ce:6a:f7:9e:f4:6a:30:4e:da:db:09:17:ba:
78:d0:03:c5:22:ad:1d:73:61:82:81:ce:d1:15:1a:
dd:66:76:22:d0:4f:a6:23:13:f1:b7:d0:67:57:28:
e7:bb:25:87:57:04:c6:c3:4f:f1:56:c1:b4:12:05:
7d:3a:9c:14:88:5e:8c:df:49:08:69:2c:00:8a:db:
d6:20:e5:f6:4d:66:38:a3:c9:f5:9d:f4:b8:24:03:
11:67:75:3c:c7:f1:75:35:dc:86:9f:e9:98:04:c7:
ba:8f:64:b8:58:64:49:27:e4:c1:25:0f:00:4e:ad:
7c:14:3b:38:1b:4d:fc:47:de:d4:a4:48:1c:81:89:
20:f5:8e:ad:2b:e2:91:51:c1:db:b3:8f:86:17:fc:
61:49:4e:03:b1:8d:97:2d:06:b4:10:51:20:78:9e:
c2:3d:5f:a8:83:a3:8e:6b:39:64:2a:ac:7a:f7:4e:
31:11
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
E6:95:82:48:3D:E8:3D:9E:0C:BA:CF:3A:EC:FF:8D:0D:E0:6A:1B:2B
X509v3 Authority Key Identifier:
keyid:CA:91:0A:ED:F9:B5:F4:F7:60:C5:A7:1C:0B:75:94:5C:33:38:F1:AB
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
55:3b:d7:52:91:70:a2:ec:8f:ff:db:ca:1b:8c:b5:73:34:10:
e8:18:3f:4f:5a:f5:75:88:99:86:a6:e8:3d:1b:2d:8c:d2:ae:
ba:e0:94:f8:a5:65:c8:4e:0e:73:e7:56:58:27:86:6e:ce:60:
df:b1:f6:6b:f5:f6:bf:29:71:af:29:f7:c7:cd:fe:26:86:04:
46:bc:89:9c:59:aa:92:d2:e4:94:f6:e0:13:ca:1c:98:33:24:
c9:aa:5e:00:c3:f9:d2:3f:7d:8f:b7:69:07:c4:f2:ea:d6:8f:
5e:10:0f:0b:27:26:b4:a5:65:30:d6:f5:c5:50:0e:b5:69:7a:
2e:ff:74:3f:35:51:c6:ac:e1:cb:31:b9:e5:80:69:53:4c:c4:
80:98:98:b4:ac:2b:cf:f6:39:96:86:3c:d4:48:da:9f:c5:62:
e0:95:d2:38:75:8f:5d:e8:55:bb:ea:6f:3c:2a:79:da:a5:89:
dd:2d:0d:a0:70:08:e1:27:19:3c:bc:e1:79:78:91:48:2c:dd:
7a:77:df:2b:ff:6f:19:ee:ab:97:12:e8:e9:81:2d:0a:04:69:
da:ab:32:51:e4:62:09:cb:80:e1:71:b5:63:c5:35:2d:ba:a9:
1f:a5:b2:43:ca:cd:1c:e2:c2:89:70:72:62:ff:8e:d1:c6:93:
d8:6a:49:4f
[snip ...]
==========================================
However, trying to verify it brings up some errors:
==========================================
openssl verify -verbose -CAfile cacert_VPN.pem -x509_strict -policy_print -
issuer_checks VPN_test_cert.pem
VPN_test_cert.pem: C = GB, O = Sundial, CN = VPN_test_XPS
error 29 at 0 depth lookup:subject issuer mismatch
C = GB, O = Sundial, CN = VPN_test_XPS
error 29 at 0 depth lookup:subject issuer mismatch
C = GB, O = Sundial, CN = VPN_test_XPS
error 29 at 0 depth lookup:subject issuer mismatch
OK
==========================================
and the asn1parser fails too:
==========================================
openssl asn1parse -in VPN_test_cert.pem
Error in encoding
139747192850088:error:0D07207B:asn1 encoding routines:ASN1_get_object:header
too long:asn1_lib.c:150:
==========================================
The cacert does not suffer from such verification or parsing errors, but
certificates signed by it, do.
The errors that the router authentication shows are:
===================================
CRYPTO_IKE.NEGOTIATION IkeInCertProcess: No certreq/cert data : 5
CRYPTO_IKE.NEGOTIATION IkeProcessPayloads :: IkeInCertReqProcess failed
CRYPTO_IKE.NEGOTIATION 100: IkeProcessPayloads failed
CRYPTO_IKE.NEGOTIATION IkeProcessData: IkeIdleProcess failed
CRYPTO_IKE.NEGOTIATION SENDING NOTIFY MSG:
CRYPTO_IKE.NEGOTIATION PAYLOAD_MALFORMED
CRYPTO_IKE.NEGOTIATION <POLICY: 100> PAYLOADS: NOTIFY
CRYPTO_IKE.NEGOTIATION NOTIFY PAYLOAD
CRYPTO_IKE.NEGOTIATION DOI: 0
CRYPTO_IKE.NEGOTIATION Protocol Id: 1
CRYPTO_IKE.NEGOTIATION Size of SPI: 16
CRYPTO_IKE.NEGOTIATION Type of notify message: 16
CRYPTO_IKE.NEGOTIATION Notify Type: Payload Malformed (16)
CRYPTO_IKE.NEGOTIATION Length of Notification Data: 0
CRYPTO_IKE.NEGOTIATION 100: Sent informational exchange message
===================================
I suspect that the malformed payload complaint is an encoding problem - but
I'm not sure. I get verification and parsing problems with the signed router
certificate, although the router accepted it and loaded it without complaints:
===================================
openssl asn1parse -in router_VPN.pem
Error: offset too large
===================================
Is there a way to overcome the above errors?
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
