On Thursday 29 Dec 2011 04:46:26 you wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Mick > > Sent: Monday, 26 December, 2011 14:01 > > <snip: CA-vs-EE DN string types> > > > 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 > > ========================================== > > Aside: for req -new without -x509, -days is ignored and useless.
Ah! Thanks I didn't know this. I thought that the CLI options prevail in any case. > > ========================================== > > 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 > > <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 > > ========================================== > > -issuer_checks can be misleading; these "errors" > are the results of internal tests for a root cert > (i.e. issued by itself) and thus quite normal. > Since the final result is OK, OpenSSL is happy. OK, its good to know that openssl is happy. > > 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: > > ========================================== > > Make sure you asn1parse a file/input containing ONLY > valid data (here dashed-BEGIN, b64 cert, dashed-END). > All(?) other openssl PEM functions accept and ignore > comments or "garbage" before BEGIN or after END, but > not asn1parse. And some openssl functions including ca > PUT such comments. You can avoid editing a copy by: > awk '/-BEGIN/,/-END/' filewithextra | openssl asn1parse > on any *nix, and on Windows if you add an awk port. Just tried this and all certs are parsed correctly. So clearly the router is not chocking on an encoding error. > > 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: > <snip> > > But as far as pleasing your router, I have no clue, sorry. Thank you Dave. Your comments have been most informative. I have raised a support request with the router manufacturer and wait to see what they come up with. -- Regards, Mick ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
