ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

[Adam Williamson]

On Tue, 2014-09-09 at 10:34 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
> > On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> > > On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > > > Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> > > > popular sites because of that change. It should not be assumed that the
> > > > users of ca-certificates are only programs using nss.
> > > 
> > > [1] is an interesting read. I get the impression that certificates are
> > > being removed as long as there is a compatible replacement that NSS can
> > > validate, based on NSS's custom strategies for certificate validation.
> > > Is this claim accurate?
> > 
> > "Custom strategies" is an interesting concept. AFAICS, the TLS standard:
> > 
> > http://tools.ietf.org/html/rfc5246
> > 
> > does not exactly define 'standard' certificate verification strategies,
> > so in a sense, they're *all* "custom". In other words, we're in good old
> > Standard Ambiguity Land here. What that doc has to say about chains,
> > AFAICS, is:
> 
> You are referring to wrong document. Certificate validation is outside
> the scope of TLS, and as you already notice it only mentions the format
> of the chain and nothing more. A Certificate Path validation algorithm
> is defined in RFC5280 by the PKIX working group which is (or was) the
> relevant group for X.509 certificates in IETF.

Ah, indeed, missed that one. Thanks.

> So it may be that everyone uses a slightly different verification
> algorithm, but we should expect at least the base-line to work. We
> should not require software to be NSS.

I think you're making a good point, but possibly too strongly...the
ca-certificates folks are just trying to keep the database strong, it's
not as if they set out to 'require software to be NSS'. As I mentioned,
the folks maintaining the ca-certificates package are the same folks
behind the Shared System Certificates feature -
https://fedoraproject.org/wiki/Features/SharedSystemCertificates - which
required a whole chunk of work to get the major TLS engines using the
same certificate store; they're certainly not unfamiliar with openssl
and gnutls, I don't think. The database uses NSS's certificate list as
its starting point because it's the strongest contender for such a role,
I think.

Your report has already been taken up for action, it appears:

https://bugzilla.mozilla.org/show_bug.cgi?id=986005

specifically:

"I think Symantec should reach out to Amazon, and potentially to other
customers, too, and suggest to remove intermediates from their server
configurations that point to these old roots."

"Brian, thanks for the pointer.  I will work with our team to see about
getting our cert chains updated for S3.  Leaving in needinfo until I
have more data." (from an Amazon employee)

so...it seems like wheels are in motion. Note that the updates for both
F19 and F20 are still in u-t and have not been pushed stable yet...as
Kai explicitly sent the update to u-t with a high auto-push threshold
and sent this email out to ask people to report cases where it caused
problems, I'd say things are working out more or less as intended,
you've raised an issue and it's being dealt with.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net