Closed konklone closed 10 years ago
On GoDaddy- Even though I generated the CSR with -sha256
, GoDaddy said it was providing a SHA1 cert. I was able to "re-key", whatever that means, and select SHA2, and I got a new cert immediately that was fine. I wonder if the SHA1/SHA2 option on GoDaddy was for the chain (vs. the hash alg on my private key)?
RapidSSL support claims that:
During the enrollment process, you will be able to select SHA2 as your hashing algorithm.
The RapidSSL certificate in question was purchased via Namecheap, so it's possible that buying directly from RapidSSL obviates the problem, but that's not much consolation — specifying SHA-2 during CSR generation should be sufficient no matter which retailers one uses to pay for the certificate.
@joshdata So "re-key" was an option visible in your GoDaddy control panel or something?
@justinmayer I was able to buy a SHA256 cert through Namecheap a week and a half ago, it's what's powering konklone.com now. That's using Comodo as the intermediary and it doesn't mention RapidSSL anywhere - is it a different offering?
Namecheap is just the reseller — the actual TLS certificate issuance occurs at the provider. Comodo is one provider, while RapidSSL is a subsidiary brand of GeoTrust.
In your case, purchasing the Comodo cert from Namecheap resulted in a proper SHA256-signed cert, whereas my RapidSSL cert purchase via Namecheap resulted in a SHA1-signed cert. Does that help clarify?
For posterity, here's the command I used to generate the CSR:
openssl req -nodes -sha256 -newkey rsa:2048 -keyout example.com.key -out example.com.csr
@konklone: Right.
Update… According to Namecheap, the fault lies squarely with GeoTrust, who apparently does not use SHA-2 by default. So once the certificate has been purchased via Namecheap and then issued by GeoTrust, Namecheap support has informed me that you must then re-issue the certificate via GeoTrust's site in order to receive a SHA-2-signed certificate. I've tested that process with the assistance of a Namecheap Live Chat support rep, and I was indeed re-issued a certificate that passes muster according to https://shaaaaaaaaaaaaa.com/. :+1:
The intermediate RapidSSL and GeoTrust CA certificates still indicate "SHA1withRSA", so hopefully they will catch up to the rest of us in due course.
Thanks for following up! And for pressing them and raising awareness with Namecheap and RapidSSL and GeoTrust -- these sorts of customer service pressure points will accelerate the transition.
I submitted a SHA2 CSR for a RapidSSL cert resold by https://cheapsslsecurity.com and got a SHA1 cert back from GeoTrust. I have contacted RapidSSL support for assistance (their knowledgebase indicates SHA-256 should be supported).
I updated the site, so I'm marking this issue as closed, but please continue to add examples on this thread and I'll update the site accordingly.
For anyone with problems with RapidSSL from any of their resellers or any other GeoTrust brand certificates:
This portal is also where you revoke your old certificate.
Thanks @Aeyoun, I added a description and link to your comment in 9af6cfb.
Gandi doesn't support SHA-2 at all. I've suggested to their support folks that this is going to be a problem in the very near future. :(
@mikewest Gandi says they're "working on it, but it's complicated :(" and imply that Windows XP SP2 will be a problem. They also encourage people to vote here on SHA-2 certs.
Their stance is super dumb, because old browser support doesn't stop them from issuing SHA-2 certificates. It's up to the site owner to make the call on whether and how to support old clients. Anyway, I'm updating the website to point to this.
That SHA-2 certs feature request is now the top item, at 100% (whatever that means): https://www.gandi.net/domain/wishlist/
RapidSSL Intermediate CA will issue new SHA-256 certificates on October 1st, according to their costumer support. Existing direct costumers will get an email advisory. Advisory status unknown for those who have bought through a reseller. I would assume the new certs will be made available here.
Regarding RapidSSL and SHA-2:
The issue at the moment is that while it is possible to get a certificate issued from RapidSSL signed with SHA-2, their intermediate certificates are not signed by SHA-2. I do not fully understand the technical implications of this, but my understanding is that the certificate chain is then somehow "downgraded" to SHA-1. Its unclear to me whether or not Google treats a SHA-2 signed-cert that has a SHA-1 Intermediate chain as safe or not.
At the moment there is no ability to establish a SHA-2 certificate chain with RapidSSL. I have been told GeoTrust's QuickSSL certificate has the same problem (but the rest of GeoTrust's catalog is not affected).
The issue should not be specific to any resellers of RapidSSL. Even if the default order form does not allow for specification of SHA2, they should all have access to it one way or another via reissue/etc.
But like I said, I am not sure if the lack of SHA-2 Intermediate Certificates will cause the cert to be identified as insecure by Google's upcoming change. I am awaiting a response from a contact at Symantec regarding this issue, but if anyone knows the answer to this, please do share.
@vtlynch, the entire chain must be SHA-2 for Chromium browsers not to downgrade a cert. Google’s Security blog post expressly states its the whole chain. HOWEVER, Chrome 39 will only downgrade if the end-entity is SHA-1 whilst Chrome 40 will look further up the chain but only hint if there are trouble further up. Chrome 41 will downgrade if any certs are SHA-1. There are six weeks (+holiday season) between releases.
Furthermore, you can reissue your RapidSSL certs as SHA-2 yourself (no matter the reseller). However, you must also upgrade their RapidSSL Intermediate CA when the updated version is available on October 1st. Should be a drop-in replacement if your own cert is SHA-2. Depending on the software, you are also going to need the GeoTrust CA SHA-2 (available now) on your server for features such as OCSP stapling as those require a full SHA-2 chain locally on the server.
@Aeyoun:
Thanks for the quick reply!
Can you provide a source for Rapid SSL's SHA 2 intermediate being available on October 1st? I have not heard about this yet.
On Monday, September 8, 2014, Daniel Aleksandersen notifications@github.com wrote:
@vtlynch https://github.com/vtlynch, the entire chain must be SHA-2 for Chromium browsers not to downgrade a cert.
Furthermore, you can reissue your RapidSSL certs as SHA-2 yourself https://github.com/konklone/shaaaaaaaaaaaaa/issues/24#issuecomment-54021941 (no matter the reseller). However, you must also upgrade their RapidSSL Intermediate CA when the updated version is available on October 1st. Should be a drop-in replacement if your own cert is SHA-2. Depending on the software, you are also going to need the GeoTrust CA SHA-2 (available now) on your server for features such as OCSP stapling as those require a full SHA-2 chain locally on the server.
— Reply to this email directly or view it on GitHub https://github.com/konklone/shaaaaaaaaaaaaa/issues/24#issuecomment-54883560 .
Vincent Lynch
@vtlynch, I cannot provide any transcript of my support chat session.. However, you can chat with the source live by clicking Live Chat on this page and asking “Will there be a new SHA-256 certificate of the RapidSSL Intermediate CA on October 1st?” They should be able to confirm it. It took first-line some time to realize what I was asking, but such a specific question should yield a fast response.
Support said it was in direct response to Google.
PS: See updated comment above for Chromium roll-out details.
@Aeyoun Ok great! I see the Google announcement is clear on the details regarding the chain as I reread it now.
I have just confirmed the same information you heard via live chat. Here are the relevant excerpts:
"Symantec has accelerated its plan to offer SHA-2 end-entity certs chaining to SHA-2 intermediates...generally available on September 15, 2014."
So RapidSSL will have a fully compatible intermediate chain by Sep 15. This comes from a contact at Symantec and will be made as an official statement soon.
from a support chat - GeoTrust claim they cannot reissue a certificate (through their GeoTrust Security Center) with SHA-2 until September 15, when they will be launching a utility to do just this.
GeoTrust will reissue, but the new SHA-2 certificate reissues are still signed with a SHA-1 root, which means the chain still requires a SHA-1 cert.
Since everyone is upgrading to SHA2 recently, we are going to make the process easier on the 15th. Otherwise you would need to cancel and place a new order.
GeoTrust will reissue, but the new SHA-2 certificate reissues are still signed with a SHA-1 root, which means the chain still requires a SHA-1 cert.
@dwradcliffe I don't think that's true - SHA-1 roots won't cause problems, in this tool or in Chrome, because they aren't verified using their digital signature. Though, if your site includes the SHA-1 root in your certificate chain (which many sites do, even though they don't need to), I'm not sure what will happen. That's discussed in #37.
Apologies if this is the wrong place to post this, but I just emailed gogetssl.com to ask about SHA-2 support. They replied 'Starting at 12th September all our SSL will be SHA-2.'
I have no affiliation with them, but they offer the lowest cost Comodo (DV) certs that I've found. I have a bunch of Gandi issued certs that I am unable to upgrade (since they don't support SHA-2 yet), so I'm looking for the cheapest possible option.
@konklone I could be wrong, but based on my tests the cert that was issued with a SHA-1 root was not valid in all browsers when I used the SHA-2 chain. I had to include a different chain that included a SHA-1 cert in order for the site to work in all browsers and pass the tests. That was also confirmed by GeoTrust support.
@dwradcliffe I'm reasonably confident that there's some other issue at play here causing your issue -- it is totally fine to use a SHA-1 root to sign SHA-2 intermediates and client certificates. If you can put both situations online so I/we can inspect them, maybe we could help figure it out.
Trustwave requires you to send the CSR in via email. Does not have a SHA-2 option on reissue (not sure about new certs). Additionally, the chain file they send along at that point does not have SHA-2 signed intermediate certificates.
@konklone I think what @dwradcliffe is saying is that the SHA-2 cert issued is signed by an intermediate SHA1-cert (Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Extended Validation SSL CA - G2
) which in turn uses a SHA1-root. If that's true, this would be pretty useful information to have on the site.
(Based on this, I'm planning on waiting until Sept 15 before re-issuing my SSL cert.)
1 & 1's certificates check out as SHA-1, and they do not seem to be taking the issue very seriously (quote from their support response to a message raising the issue): "We have received an escalated case support regarding the SHA-1 algorithm of your SSL certificate. Unfortunately, at the moment we do not have a time frame when the algorithm of all our SSL certificates will be switched to SHA-2. When we will start the transition from SHA-1 to SHA-2 algorithm all our customers will receive an email in regard to this with the necessary steps."
This is not my intention to advertise DNSimple here, however I just want to let you know that if you feel you want to update the provider list, as of today all SSL certificates purchased via DNSimple are SHA-2.
We used RapidSSL in the past, and I confirm that they have no immediate intention/interest to switch to SHA-2 by default. They don't even obey to the hash algorithm you specify in the CSR (see #50). The option they provide is to order a cert and then reissue it using their portal.
Namecheap/Comodo sent me a SHA1 cert in response to a SHA256 CSR. I spent about 20 minutes (mostly idling, waiting for emails and such) in text-chat with Namecheap support to get a corrected SHA256 cert. Hope this helps...
EDIT: Ugh, this isn't correct. I was running openssl x509
against the chained certificate, and it told me SHA1 because that's the root's signature. I double-checked against the specific certificate and lo and behold they sent me the right thing in the first place.
Phew! For a second I was worried, I'd had a good experience with Namecheap/Comodo. Glad it worked out.
Some vendors I have seen are ignoring the CSR. Geotrust, Rapid SSL, Thawte (Symantec) and Comodo are only looking at the selection made in the enrollment form. This is true wether you buy from them or through a reseller because it is how their API is now working.
During generation these CAs certs should have a selection somewhere to choose SHA-1 or SHA-2 in the webform. If not, I suspect the site is returning an API call to Comodo anyway, which is specifying one or the other.
Yeah, I updated the language in https://github.com/konklone/shaaaaaaaaaaaaa/commit/ff917078ae096a10497a08bd188c12bef257947d to be less direct about the -sha256
flag -- it doesn't actually "request" that the cert be signed with SHA-2, it signs the CSR itself as SHA-2.
Digicert issues SHA-2 certificates by default if you purchase a new one (and your request was done properly with -sha256). However, if you rekey a current certificate, you must click ADVANCED OPTIONS on the CSR page and click the "Use a SHA-2 signature hash algorithm" option.
@Aeyoun I've just spoken to RapidSSL and representative "James" told me "A full SHA-2 CA chain will be available in mid October." So apparently that date has slipped.
I was finally able to get a SHA-2 certificate with a SHA-2 chain from GeoTrust. I'm told that by selecting SHA-2 as the hashing algorithm during the reissue process, that will also cause the cert to be signed by a SHA-2 root (as of this week). Also note, the intermediate cert linked from their emails is NOT the correct cert to use. I had to dig around to find it. Their cert check page provides links to some of the proper intermediate certs.
RapidSSL's SHA-2 chain certificate is now available here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO26459
You only need the first certificate in that chain; the second one is a root certificate that's trusted by virtually all browsers.
Maybe I need to reissue my cert? Qualys SSL Test doesn't goes well with my current SHA-2 cert and the new SHA-2 intermediate. Firefox still uses a SHA-1 chain instead of the new SHA-2 intermediate.
@cadusilva you aren't providing the intermediate cert. Are you using nginx or apache?
@jonnybarnes nginx. The cert file includes the domain cert and the SHA-2 intermediate.
Edit: for the record, Shaaaaaaaaaaaaa test says "Nice" about the chain.
The only thing I can think of is that the certificate www.amigogeek.net
isn't actually signed by the certificate RapidSSL SHA256 CA - G3
.
@cadusilva Everything seems OK on Firefox though:
@jonnybarnes I made a reissue and now everything is fine. SHA-2 certs issued before the release of the SHA-2 intermediate needs to be reissued in order to properly work, as we can see.
@cadusilva excellent :)
@cadusilva @AGWA Great research -- I've updated the site to link to RapidSSL's intermediates, and to note a re-issue may be required.
Eric,
I have confirmed with Symantec today that ALL certificates signed by a SHA-1 Intermediate must be reissued so they can be signed by the new SHA-2 Certs. This applied even to certificates which are signed as SHA-2 at the server certificate level.
For Symantec brands, this means all RapidSSL and QuickSSL certificates issued before Sept 15, 2014 (when they released SHA-2 intermediates) and expiring after Jan 1st 2016 need to be reissued.
I don't entirely understand why. I guess because the issuer is hard coded into the cert as shown in the above screenshot.
@pfletch101 Is 1&1 just a reseller? Their page looks like a GeoTrust passthrough.
Yes, I assume so, but I know of no way of bypassing their system to get a SHA-2 certificate for my site direct from the source.
@justinmayer is having trouble with RapidSSL. @joshdata had trouble with GoDaddy, he was told he had to "re-key" his certs.
Any hiccups people might run into when responding to the site should be proactively listed.