81–90 of 136 posts
Earlier quoted context omitted.
The root CA, USERTrust, is SHA-1 signed. Everything else is SHA-2 however as you said.
That's right, but the root cert is not sent by the server (in my case). More importantly, SHA-1 isn't a problem for root certs, as their signature is not used to verify their integrity.
The issue here is old clients... Does anyone know how old clients would handle SHA-2 certs, would they just get a warning saying the site is insecure but still be able to visit the site over an encrypted connection or do they break completely... I guess - I'll have to run a few tests this afternoon and see how windows XP performs.
Please let us know. Here's a table showing when SHA-2 support was added to various browsers. http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...
Everyone is vulnerable: https://www.google.com , https://www.facebook.com , https://www.svyft.com as per the link provided in the article ( https://shaaaaaaaaaaaaa.com )
Either way, Google has made it pretty clear that they want at least SHA-2 certificates, which, so long as they call it out in address bars, warning interstitials, and make noise about SERP impact, means that this is the way things are going.
Earlier quoted context omitted.
That's right, but the root cert is not sent by the server (in my case). More importantly, SHA-1 isn't a problem for root certs, as their signature is not used to verify their integrity.
Then what is the signature for?
There's less chance to screw things up if the spec says that root certs should look exactly like all other certs, rather than trimming out parts that shouldn't be needed.
Earlier quoted context omitted.
If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
Windows XP SP 2 (SP 3 is fine) and early Android, I believe, are the clients that don't support certs later than SHA-1.
I'm a developer, but I'm not responsible for SSL cert acquisition.
The ONLY way I can get the people responsible for that to stop using SHA-1, is to tell them that user's browsers are sending a warning/error message on it.
I will eagerly await Chrome doing that.
Just to be clear, since I often end up confused on this point — is the use of SHA-1 with HMAC, outside of the context of SSL, still acceptable?
So where is the fully automated solution for rotating certificates? I've been looking for a CA who will provide an API to send the cert request, an easy way to prove the domain ownership which doesn't involve SMTP, and the signed cert handed straight back from the API, but haven't found it. So far the most I've been able to streamline my certificate requests is to automate generating the CSR, skip setting the MX reco…
I'm working on this problem: https://sslmate.com/ Right now it's just a command line client, but a public API is in the works. And this week we'll be announcing a solution to the cert rotation problem (basically, you'll be able to drive your renewals from cron - it's going to be really cool). You might want to follow @sslmate on Twitter - this is just the beginning of some very exciting stuff for automating SSL cert…
The /link API is interesting, versus generating a token on your site through the UI. You might want to consider allowing an explicit $$ limit on /buy, since you store the api-key in the clear (albeit in a config file set to 0600).
It looks like you still rely on being able to receive an email on the domain and click an approval link, though. I'm sure this is a RapidSSL requirement, but it makes full automation more complex (certainly not impossible).