On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
>> I believe that we must contact Amazon and Symantec about this issue.
>> Amazon should remove the second intermediate, ending the path with the
>> G5 intermediate. This will allow openssl to find the trusted root CA.
>> Also, Symantec should reach out to all of their customers and tell them
>> you update their configuration.
>> I will contact them.
> Great! Thanks. Should I open ticket against ca-certificates to keep
> track about this issue?
There was a short discussion here:
In this particular case, because it works with NSS/Firefox, the admins
don't think it's necessary to reconfigure?
I think it doesn't help to track the issue with this particular web
site. I've been told this is a default configuration, which had been
recommended by the CA to the customers for a long time, in order to
achieve maximum compatibility with clients. So it's unlikely to get all
sites changed, for two reasons, worry of site admins to break
compatibility, and the fact that it's unrealistic to reach and convince
all site admins.
This means, we'll either have to find a software solution (such as
getting gnutls/openssl enhanced to construct alternative chains), or
wait with weak 1024-bit removals by default, until all involved server
certificates have expired, which would be very unfortunate (and which
might take several years, because of the transitioning trick, that
causes recently issued certificates to appear to have been issued by
both the weak legacy and stronger replacement root ca cert).
I am in favor of the former solution, but the later is good as well.
Nevertheless, I am still unsure how to proceed with RubyGems. Should I
ship the bundled certificates again? Or should I wait until somebody