Hi, On Monday 21 July 2014 21:25:55 Kurt Roeckx via RT wrote: > On Mon, Jul 21, 2014 at 08:29:47PM +0200, Stefanos Harhalakis via RT wrote: > > Hi there, > > > > Commit 3009244da47b989c4cc59ba02cf81a4e9d8f8431 changed the global_mask to > > B_ASN1_UTF8STRING (see bellow). > > > > The mask is used to determine the least type of a string and the change > > practically makes this scan (as performed by type_str()) a no-op since the > > results is now always B_ASN1_UTF8STRING. This breaks compatibility. > > > > As a result of the change, all newly generated certificates have the > > relevant parts of the name set as UTF8 strings. This for example broke > > racoon's usage of certificates when it's using an older version while the > > certificates are being generated by a newer version, because the name > > comparison it performs, now fails. > > I'm not sure I understand. Is there maybe a problem that the CA > certificate used something other than UTF-8 and that new generated > certificates use UTF-8 in the issuer and so the chain validation > fails?
I see two issues here: 1) The practical (and bigger) one is that this breaks (at least) Debian stables' racoon. Example scenario: * Box A runs racoon with older openssl * Box B connects to A (IPsec using racoon) using a cert. With a certificate that was generated from an older openssl version everything is fine. When a new certificate on B is generated with the new openssl version then the new cert gets the UTF8 entries. Racoon is configured with: verify_identifier on; peers_identifier asn1dn "C=UK, CN=test" Now racoon on A that runs old openssl xreates an X509Name based on the asn1dn in the config file. The X509Name has both C and CN as PRINTABLESTRING. Racoon tries to match this against the remote cert which now has C as PRINTABLESTRING and CN as UTF8STRING. Racoon compares for equality both the type and the data. This is obviously wrong but it used to work so far. Since the types differ now, it breaks out of nowhere and it's impossible to debug unless you start compiling and testing your own racoon and openssl versions it order to pinpoint the exact issue. 2) The theoretical one is that after the change there's no point in scanning the name any more and try to reduce the type since it'll always be UTF8STRING unless dictated differently for an entry. As such, either the scanning is wrong or this convention. > Please note that you can set the old behavior back with the > ASN1_STRING_set_default_mask() call. Yes, I noticed this. However I don't have control over Debian's racoon (stable) which is the affected one. If you decide to keep it like this though I'll follow up with a suggested patch for that. Thanks, Stefanos ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
