SSL certificate chain validation issues

Mark Doliner mark at
Mon Jun 23 12:17:40 EDT 2014

On Mon, Jun 23, 2014 at 7:51 AM, Daniel Atallah <datallah at> wrote:
> Perhaps I'm missing something, but it doesn't seem right that we're treating
> certs without basic constraints as if they are CAs.

Yeah, this is something I'm not sure about. Thanks for bringing it up.

> Is the thought that any cert that has a path back to a trusted root will
> have basic constraints?

I think so but I'm not sure. It's hard to tell but I think the NSS
verify function allows a cert to sign if it doesn't have the basic
constraint extension and the nsCertType is an SSL CA. See the
cert_VerifyCertChainOld() function at
Specifically how they set the isca boolean.

And if you think about it how the extension would have been rolled
out, it seems like certs without the basic constraint extension would
need to have been allowed for backward compatibility. So it seems like
CAs would have changed to only sign certs which have the extension.

I tested just now and it looks like our major PRPLs all have the
extension, so maybe we SHOULD require it and see if people complain?

> I'm not intimately familiar with either the gnutls or NSS APIs, but apart
> from the question about missing basic constraints it seems ok to me.
> I guess if this is the best that we can do for gnutls at the moment, that
> seems ok, but not ideal.
> My preference would be to include something like my complete NSS fix even if
> we can't do the same for gnutls.

Yeah, I guess I slightly changed my mind from what I said in my April
21st email. I mildly prefer adding the extra checks for basic
constraints (for both NSS and gnutls) instead of replacing it. My
thinking was that it would be less error-prone. But I don't have a
strong opinion. I'm fine with adding the check for gnutls and using
your patch for NSS.

Anyone else have an opinion?

More information about the security mailing list