4 ms·

Google, CloudFlare and a handful of the technically sophisticated organizations have the ability to return different certificates depending on the connecting br

Google, CloudFlare and a handful of the technically sophisticated organizations have the ability to return different certificates depending on the connecting browser. Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. I assume that's not what you're doing, but please correct me if I'm wrong. If you are returning two different certificates for two different situations at Google.com, the least you could do is dedicate some of your vast engineering resources to making the plugins to support such a setup production ready. If Google uses it's technical sophistication to avoid the pain while the rest of the web burns then that's, at best, hypocritical. I'll make you this deal: if you do it for Apache, we'll do it for NGINX. That's the right thing to do. As would be making SSL certs free, but that's a conversation for another day.

ivanr 12y ago
Actually, Apache already supports deployments with more than one certificate for the same host: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertifi...
- agwa 12y ago
  Is it possible to specify both a RSA-SHA1 cert and a RSA-SHA256 cert that way, or would it have to be RSA-SHA1 and ECDH-SHA256? Apache/OpenSSL would have to assume that pre-TLSv1.2 clients support only SHA1 because there's no signature_algorithms extension, but for TLSv1.2 clients can Apache/OpenSSL choose between a RSA-SHA1 cert and a RSA-SHA256 cert? The reason I ask is because ECDH certs seem to be even harder to come by than RSA-SHA256 certs right now.
  - ivanr 12y ago
    I haven't tried, but I think at the moment Apache supports only multiple certificates with different private key algorithms. Anything else would have to be implemented in custom code. IIRC, OpenSSL 1.0.2 (not yet released) has better support for multiple certificate chains on the same server.
agl 12y ago
> Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. That's certainly the plan. What did I say that suggests otherwise?
- agwa 12y ago
  Will www.google.com continue to be available over HTTP? If so, the old browsers will still be able to use Google search by simply avoiding HTTPS. That would lessen the impact on Google, in contrast to sites that follow best practice and unconditionally redirect HTTP to HTTPS.

ivanr 12y ago

Actually, Apache already supports deployments with more than one certificate for the same host: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertifi...

agwa 12y ago
Is it possible to specify both a RSA-SHA1 cert and a RSA-SHA256 cert that way, or would it have to be RSA-SHA1 and ECDH-SHA256? Apache/OpenSSL would have to assume that pre-TLSv1.2 clients support only SHA1 because there's no signature_algorithms extension, but for TLSv1.2 clients can Apache/OpenSSL choose between a RSA-SHA1 cert and a RSA-SHA256 cert? The reason I ask is because ECDH certs seem to be even harder to come by than RSA-SHA256 certs right now.
- ivanr 12y ago
  I haven't tried, but I think at the moment Apache supports only multiple certificates with different private key algorithms. Anything else would have to be implemented in custom code. IIRC, OpenSSL 1.0.2 (not yet released) has better support for multiple certificate chains on the same server.

agl 12y ago

> Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. That's certainly the plan. What did I say that suggests otherwise?

agwa 12y ago
Will www.google.com continue to be available over HTTP? If so, the old browsers will still be able to use Google search by simply avoiding HTTPS. That would lessen the impact on Google, in contrast to sites that follow best practice and unconditionally redirect HTTP to HTTPS.