Le 16/12/2011 18:45, Mick a écrit :
[...]
Indeed, the message was rather esoteric and it did not offer a way out - e.g.
it could have advised to change "match" to "supplied" in openssl.cnf, or to
ensure that the encoding between the CSR and ca is the same.
I think what confused me is that by uploading the cacert to the router I would
expect the router to respect the cacert's encodings. It evidently did not.
It doesn't need to :)
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.
Or you could keep your CA certificate as is, change the policy
directives (from "match" to "supplied"), and manually check the requests.
Or code something with "openssl req -text -nameopt
multiline,utf8,-esc_msb ...", extracting the RDNs, comparing with what
is set in the CA certificate (the "-nameopt ..." argument will convert
everything into UTF8, easing the comparison), whence performing your own
validation.
--
Erwann ABALEA
-----
Désolé.
Ta gueule.
-+- LC in : Guide du Neuneu Usenet - Neuneu exaspère le dino -+-
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
