> From: owner-openssl-...@openssl.org On Behalf Of Gabriel Aubut-Lussier > Sent: Monday, January 13, 2014 20:37
> I have integrated OpenSSL in a small client/server prototype recently > and I've been left wondering about two issues I've encountered. > > 1. I have successfully created a certificate signed by an expired > certificate authority. Maybe there is some edge use case where this > kind of behaviour can be required, but shouldn't OpenSSL throw an > error when signing with an expired autority? And then, in order to > accomodate edge use cases allow an additionnal parameter to ignore > such an error? > I'm guessing you used openssl commandline 'ca' or 'x509 -req'? commandline is not designed to be production quality software (unlike the libraries, which are or at least try to). It has lots of missing, limited, or confusing features. But note expired is not the only way a cert can be invalid; do you want to check revoked, or not chained correctly, or not suitable KeyUsage, etc, etc? If so you could just use a script to do commandline 'verify' on the CA cert before using it as an issuer. > 2. I have successfully established a connection with a server using > the certificate I mentionned above : the certificate signed by an > expired autority. Why does the default behavior allow me to establish > such a connection without any warning? It would be much more secure to > raise an error in such a case and require explicit approval through > some parameter to overlook the issue with the server's certificate. > Do you mean with commandline s_client? Similar to above that's intended mostly as a test tool; it overrides *all* validation errors and proceeds with the connection. It does display "Verify return code" which is a warning if you look and here is "10 certificate has expired". A real client should at least warn. The ones I can test easiest: IE9 on Win7 says expired or not yet valid; Chrome on Win7 says not yet valid, which is misleading but at least a warning; Firefox gives the exact warning issuer cert has expired. As expected curl+openssl fails (10 and alert expired) unless -k. Alarmingly, Java (Suncle 6 and 7 JSSE) accepts this chain -- although 7 (only) rejects the more reasonable case of a child cert that *starts* during issuer validity and extends after. IME real CAs won't issue certs that end after parent end, much less begin after parent end, because of course they aren't usable outside the parent (or at all). 5280 requires checking "current" (validation) time against validity period for every cert in the chain, which would be unnecessary if we knew the leaf's period nests within (all) parent(s), although it does no harm. Modest googling finds me only www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt complains in 2000 it's underspecified (along with much else) access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/managing-ca-related-profiles.html says strict nesting is the default but can be overridden in some cases http://technet.microsoft.com/en-us/library/cc700843.aspx says strict nesting is required, but it isn't clear if they mean relier, CA aka CertServices, or both. Certainly the versions of IE I've used (as relier) with test setups that start during and end after have never complained during the intersection period. And remember that in addition to the cert being correctly chained to a root, within period, not revoked and within usage, for SSL servers it usually must also have name (Subject or SAN) matching what client wants (e.g. from URL for HTTPS). openssl to date doesn't check name at all, though I think I remember a post saying it will be added in 1.0.2. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
