List any complications with common CAs in getting SHA-2 certs

[konklone]

@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.

[JoshData]

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)?

[justinmayer]

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.

[konklone]

@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?

[justinmayer]

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?

[justinmayer]

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

[JoshData]

@konklone: Right.

[justinmayer]

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/. 👍

The intermediate RapidSSL and GeoTrust CA certificates still indicate "SHA1withRSA", so hopefully they will catch up to the rest of us in due course.

[konklone]

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.

[da2x]

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).

[konklone]

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.

[da2x]

For anyone with problems with RapidSSL from any of their resellers or any other GeoTrust brand certificates:

1. Login to GeoTrust products using your FQDN and the email used to request the certificate
2. Follow the login link sent by email
3. Click reissue
4. Provide a new CSR and choose SHA-256 from the drop-down

This portal is also where you revoke your old certificate.

[konklone]

Thanks @Aeyoun, I added a description and link to your comment in 9af6cfb.

[mikewest]

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. :(

[konklone]

@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.

[mathiasbynens]

That SHA-2 certs feature request is now the top item, at 100% (whatever that means): https://www.gandi.net/domain/wishlist/

[da2x]

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.

[vtlynch]

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.

[da2x]

@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.

[vtlynch]

@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
#24 (comment)
(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
#24 (comment)
.

Vincent Lynch

[da2x]

@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.

[vtlynch]

@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.

[cwholt]

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.

[dwradcliffe]

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.

[konklone]

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.

[ghost]

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.

[dwradcliffe]

@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.

[konklone]

@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.

[NotSqrt]

Just lost an hour trying to understand why Chrome 40 would warn me of obsolete security parameters that might be a problem for future versions of Chrome.. It was only a local issue. On a more recent ubuntu, there was no problem.

My chain is SHA256 certificate -> RapidSSL SHA256 certificate -> GeoTrust SHA1.

As said by #24 (comment), it seems that there's no need to worry about the root being SHA1. Ssllabs says "Weak or insecure signature, but no impact on root certificate".

[konklone]

@NotSqrt I bet it's because of a Chrome issue :/ Discussed here, your browser can improperly cache the SHA-1 paths it's seen on prior sites using the same certs: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/pKTfaA8KqcQ

I believe a fix is rolling out in the next version of Chrome.

[NotSqrt]

Probably Chrome + outdated NSS lib.

[chris-erickson]

I have been unable to build a working RapidSSL OCSP configuration using a newly issued SHA2 cert on nginx. Has anyone had success willing to share the proper certs and configuration details?

[jonnybarnes]

Your serer block should contain something like:

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
resolver_timeout 10s;
ssl_trusted_certificate /etc/ssl/private/startssl.class2.ocsp.crt;

The last line is key. It should contain a certificate chain with the root certificate and the intermediate certificate.

Another issue with nginx and OCSP is if you use virtual hosts. One of them must be designated the default_server and that host must have stapling enabled, otherwise stapling will not work on any virtual host.

[konklone]

Another thing I've noticed with nginx is that stapling won't appear to be working if you test it, e.g. with SSL Labs, right after restarting the server. It takes a request or two to start working.

[jonnybarnes]

SSL Labs fails me for OCSP. Yet, if I check manually with OpenSSL, namely running the following (sourced from this random blog):

echo QUIT | openssl s_client -connect jonnybarnes.uk:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

I get a valid OCSP response!

[jonnybarnes]

And with that SSL Labs says I have OCSP enabled.

[sporkman]

Namecheap has a pretty nice list of many intermediate certs here:

https://www.namecheap.com/support/knowledgebase/article.aspx/9393/69/where-do-i-find-ssl-ca-bundle

After trying many of the RapidSSL options from their own site for a wildcard cert and still getting the Chrome warning (but an A+ at SSL Labs, go figure), the RapidSSL wildcart intermediate pack worked for me in Chrome.

[skunkworker]

If anyone is having problems with rapidssl with a sha256 cert, make sure that the cert was issued after they changed their intermediate from sha1 to sha256, I had previously gotten a cert before the change and even though it was sha256 it wasn't working. After re-issuing there was no problem.

[gmodea]

Chrome 41 on Mac OSX and Chrome OS is now doing the "neutral security" thing for Rapid SSL SHA-256 certs that expire after 1/1/2017 because there's still a SHA-1 certificate in the chain (GeoTrust Global CA). Neutral security means no "green lock" icon, but no explicit warning either. I'm waiting for a response from them, but unless they plan on updating their whole certificate chain very soon, the answer will probably be requesting expiration of 12/31/2016 or earlier when having certificates issued.

UPDATED: RapidSSL documents on using their intermediate CA "bundles" all include the GeoTrust intermediate CA signed by Equifax. That intermediate ("primary intermediate") is no longer needed with the SHA-256 certificates currently being issued, you only need the RapidSSL secondary intermediate. If you have the additional SHA-1 intermediate, then SSLLabs will show two certification paths, and the second one, with the SHA-1 signed GeoTrust certificate, will cause Chrome to display the neutral security warning.

Tl; Dr: for Rapid SSL intermediate certificates, you only want the one ending in "mJMcCaY". If you also have the one ending in "mHyhD8S", it will trigger Google's SHA-1 chain warning.

[AppFull]

Too much problem, not gonna renew RapidSSL time to move on ;p

[charan9]

how i can get intermediate and root from geotrust portal ? i am dont have login access.

i have intermediate, looking for root.

-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTQwODI5MjEzOTMyWhcNMjIwNTIwMjEzOTMyWjBHMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEgMB4GA1UEAxMXUmFwaWRTU0wg
U0hBMjU2IENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv
VJvZWF0eLFbG1eh/9H0WA//Qi1rkjqfdVC7UBMBdmJyNkA+8EGVf2prWRHzAn7Xp
SowLBkMEu/SW4ib2YQGRZjEiwzQ0Xz8/kS9EX9zHFLYDn4ZLDqP/oIACg8PTH2lS
1p1kD8mD5xvEcKyU58Okaiy9uJ5p2L4KjxZjWmhxgHsw3hUEv8zTvz5IBVV6s9cQ
DAP8m/0Ip4yM26eO8R5j3LMBL3+vV8M8SKeDaCGnL+enP/C1DPz1hNFTvA5yT2AM
QriYrRmIV9cE7Ie/fodOoyH5U/02mEiN1vi7SPIpyGTRzFRIU4uvt2UevykzKdkp
YEj4/5G8V1jlNS67abZZAgMBAAGjggEdMIIBGTAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUw5zz/NNGCDS7zkZ/oHxb8+IIy1kwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMEwGA1UdIARF
MEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3Ry
dXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEBCwUAA4IBAQCjWB7GQzKs
rC+TeLfqrlRARy1+eI1Q9vhmrNZPc9ZE768LzFvB9E+aj0l+YK/CJ8cW8fuTgZCp
fO9vfm5FlBaEvexJ8cQO9K8EWYOHDyw7l8NaEpt7BDV7o5UzCHuTcSJCs6nZb0+B
kvwHtnm8hEqddwnxxYny8LScVKoSew26T++TGezvfU5ho452nFnPjJSxhJf3GrkH
uLLGTxN5279PURt/aQ1RKsHWFf83UTRlUfQevjhq7A6rvz17OQV79PP7GqHQyH5O
ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh
gP8L8mJMcCaY
-----END CERTIFICATE-----

PLEASE HELP.

[gmodea]

@charan9 You shouldn't need the root unless you're attempting to support very old clients with very old trusted root lists. The cert ending in JMcCaY should terminate at a trusted GeoTrust Global Root certificate pre-installed on modern OSes.

That said, if you ARE supporting ancient clients, you can't include the root certificate in your intermediate chain -- they would need to install the roots themselves. They can get the required root certificate from the link below, I believe the certificate in question is listed as "Root 2 - GeoTrust Global CA":

https://www.geotrust.com/resources/root-certificates/

[cvc1989]

Ran into an issue while generating a CSR for Symantec, it kept telling me that the CSR was not in a valid format:

"The submitted CSR is not a properly formatted CSR. Generate and submit a valid CSR"

Found this advice in their documentation, which fixed it:

"Please do not enter an email address, challenge password or an optional company name when generating the CSR."

Hope this helps.

[charan9]

Hi,
While generating CSR in Linux server for wildcard certificate i am getting "WAS NOT ABLE TO CREATE A CERTIFICATE FOR THIS HOST: PRESS RETURN TO EXIT". This error i get at the end of the generation, like after giving Country name, OU, Company name.....etc..,

wildcard : _.abcdinteractive.com
tried : _.abcdinteractive.com

Google is not helping on this error, if some one can guide in this it will be great help for me.

Thanks
Charan

[jonnybarnes]

For a wildcard cert you need to set the CN to *.domain.com

—
Sent from Mailbox

On Thu, Apr 30, 2015 at 12:44 PM, charan9 notifications@github.com
wrote:

Hi,
While generating CSR in Linux server for wildcard certificate i am getting "WAS NOT ABLE TO CREATE A CERTIFICATE FOR THIS HOST: PRESS RETURN TO EXIT". This error i get at the end of the generation, like after giving Country name, OU, Company name.....etc..,
wildcard : _.abcdinteractive.com
tried : _.abcdinteractive.com
Google is not helping on this error, if some one can guide in this it will be great help for me.
Thanks

Charan

Reply to this email directly or view it on GitHub:
#24 (comment)

[charan9]

Jonny... my mistake .. thats typo i used *.abcdinteractive.com for generating.

[jonnybarnes]

Can you possibly copy/paste the whole output into a gist?

—
Sent from Mailbox

On Thu, Apr 30, 2015 at 12:55 PM, charan9 notifications@github.com
wrote:

Jonny... my mistake .. thats typo i used *.abcdinteractive.com for generating.

Reply to this email directly or view it on GitHub:
#24 (comment)

[charan9]

jonny
Please find image here.

Thanks
Charan

[gmodea]

@charan9 not sure what you're using there to generate a certificate request, but I'd recommend you go the plain old command line route. These instructions should get you going: http://www.rackspace.com/knowledge_center/article/generate-a-csr-with-openssl

[chris-erickson]

For those with RapidSSL, I think I got OCSP working now with the SHA256 certs. I say think because SSLLabs test is saying no, but openssl testing commands are saying yes. Here are the keys I had to use:

-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTQwODI5MjEzOTMyWhcNMjIwNTIwMjEzOTMyWjBHMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEgMB4GA1UEAxMXUmFwaWRTU0wg
U0hBMjU2IENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv
VJvZWF0eLFbG1eh/9H0WA//Qi1rkjqfdVC7UBMBdmJyNkA+8EGVf2prWRHzAn7Xp
SowLBkMEu/SW4ib2YQGRZjEiwzQ0Xz8/kS9EX9zHFLYDn4ZLDqP/oIACg8PTH2lS
1p1kD8mD5xvEcKyU58Okaiy9uJ5p2L4KjxZjWmhxgHsw3hUEv8zTvz5IBVV6s9cQ
DAP8m/0Ip4yM26eO8R5j3LMBL3+vV8M8SKeDaCGnL+enP/C1DPz1hNFTvA5yT2AM
QriYrRmIV9cE7Ie/fodOoyH5U/02mEiN1vi7SPIpyGTRzFRIU4uvt2UevykzKdkp
YEj4/5G8V1jlNS67abZZAgMBAAGjggEdMIIBGTAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUw5zz/NNGCDS7zkZ/oHxb8+IIy1kwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMEwGA1UdIARF
MEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3Ry
dXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEBCwUAA4IBAQCjWB7GQzKs
rC+TeLfqrlRARy1+eI1Q9vhmrNZPc9ZE768LzFvB9E+aj0l+YK/CJ8cW8fuTgZCp
fO9vfm5FlBaEvexJ8cQO9K8EWYOHDyw7l8NaEpt7BDV7o5UzCHuTcSJCs6nZb0+B
kvwHtnm8hEqddwnxxYny8LScVKoSew26T++TGezvfU5ho452nFnPjJSxhJf3GrkH
uLLGTxN5279PURt/aQ1RKsHWFf83UTRlUfQevjhq7A6rvz17OQV79PP7GqHQyH5O
ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh
gP8L8mJMcCaY
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3Qg
R2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD9
9BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdq
fnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDv
iS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU
1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+
bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoW
MPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTA
ephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1l
uMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKIn
Z57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfS
tQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcF
PseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Un
hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
-----END CERTIFICATE-----

Credit for this goes here.

FWIW, maybe someone can help me with why my SSLLabs test is giving me a "No" on OCSP stapling, but this command is not:

> echo QUIT | openssl s_client -connect example.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Result:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: XXXXX
    Produced At: Jul  9 05:28:14 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: XXXXX
      Issuer Key Hash: XXXXX
      Serial Number: XXXXX
    Cert Status: good
    This Update: Jul  9 05:28:14 2015 GMT
    Next Update: Jul 16 05:28:14 2015 GMT

[charan9]

Hi All,
By Chance i have entered to certificate domain and i have started working on installing certificates in F5 loadbalancer since 6 months. i have 5 plus years of experience on linux production support.

What could be the best option to continue in certificate domain. what kind of training i need to take to
be competitive in this field.

Any advices will be appreciated.

Thanks
Charan

[charan9]

i am generating sha1 csr with 2048 bit and using for procuring sha256 certificate.

Will this create any security issue in future ? as we are migrating to sha2.

Thanks
Charan

[konklone]

@charan9 Most places don't care what sig your CSR uses. I suspect that by now, in mid-2015, "most" has become "all", and you should be fine no matter what. Ring in here if you see any issues.

[godenji]

sha-2 intermediate (see my reply below) under sha-2 root released 3 weeks ago.

No dice after the reissue though, get incomplete cert warning with SSL Labs...sigh ;-)

[godenji]

Got it sorted, with the help of this excellent github project.

No idea where the intermediate cert (that the above tool found) came from, but it's not the one provided by GeoTrust in my comment above.

[fomojola]

After some struggle with the Geotrust certs, it appears there's an extra cross root you can add that fixes verification errors on certain platforms (in my case it was a customer complaining about Pidgin on Windows XP showing a certificate warning). The cross root is at https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426 and the entire intermediate cert needed to get it to work without errors is this:

-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTQwODI5MjEzOTMyWhcNMjIwNTIwMjEzOTMyWjBHMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEgMB4GA1UEAxMXUmFwaWRTU0wg
U0hBMjU2IENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv
VJvZWF0eLFbG1eh/9H0WA//Qi1rkjqfdVC7UBMBdmJyNkA+8EGVf2prWRHzAn7Xp
SowLBkMEu/SW4ib2YQGRZjEiwzQ0Xz8/kS9EX9zHFLYDn4ZLDqP/oIACg8PTH2lS
1p1kD8mD5xvEcKyU58Okaiy9uJ5p2L4KjxZjWmhxgHsw3hUEv8zTvz5IBVV6s9cQ
DAP8m/0Ip4yM26eO8R5j3LMBL3+vV8M8SKeDaCGnL+enP/C1DPz1hNFTvA5yT2AM
QriYrRmIV9cE7Ie/fodOoyH5U/02mEiN1vi7SPIpyGTRzFRIU4uvt2UevykzKdkp
YEj4/5G8V1jlNS67abZZAgMBAAGjggEdMIIBGTAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUw5zz/NNGCDS7zkZ/oHxb8+IIy1kwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMEwGA1UdIARF
MEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3Ry
dXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEBCwUAA4IBAQCjWB7GQzKs
rC+TeLfqrlRARy1+eI1Q9vhmrNZPc9ZE768LzFvB9E+aj0l+YK/CJ8cW8fuTgZCp
fO9vfm5FlBaEvexJ8cQO9K8EWYOHDyw7l8NaEpt7BDV7o5UzCHuTcSJCs6nZb0+B
kvwHtnm8hEqddwnxxYny8LScVKoSew26T++TGezvfU5ho452nFnPjJSxhJf3GrkH
uLLGTxN5279PURt/aQ1RKsHWFf83UTRlUfQevjhq7A6rvz17OQV79PP7GqHQyH5O
ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh
gP8L8mJMcCaY
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3Qg
R2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD9
9BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdq
fnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDv
iS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU
1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+
bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoW
MPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTA
ephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1l
uMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKIn
Z57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfS
tQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcF
PseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Un
hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw
WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE
AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m
OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu
T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c
JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR
Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz
PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm
aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM
TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g
LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO
BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv
dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB
AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL
NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----

For Geotrust certs (in my case, the RapidSSL domain validation certificates) this resolved all my verification errors on every platform.

[charan9]

Hi ALL,
i was binding intermediate and root to main thwate ssl sha256 certificate and chain was listing properly on ssl checker, now i am getting (The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate.) with red arrow mark.

https://www.sslshopper.com/ssl-checker.html#hostname=moneycenter.yodlee.com

i am using below chain to link. Please suggest why i am getting this and which chain i need to bind.

INTERMEDIATE:- (thawte_SSL_SHA2_CA_G2 )
-----BEGIN CERTIFICATE-----
MIIEsjCCA5qgAwIBAgIQFofWiG3iMAaFIz2/Eb9llzANBgkqhkiG9w0BAQsFADCB
qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw
MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV
BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMTMxMDMxMDAwMDAwWhcNMjMx
MDMwMjM1OTU5WjBBMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMu
MRswGQYDVQQDExJ0aGF3dGUgU1NMIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCy/Ab7BJPS6lkgO0SFl1I55xDweuCwlEDaRvgMKLu5zmA4
P9LYEUIbka1J7o/H3mzeN2/9iyA8bed009zVJIhBgInuNr7E1b6NUxOq5KW4kwq+
7NrNPNQyVu/QTqC4l7s5UB5uZcP9ss7gWalICcb+vq78PjuBIJeLj0bfYGQHdbsb
hjifR3s0zqHRl6122J+3Jtt5gDZI8sU3+NkyrnykU4HHmaFUOC9PdaC7WqW7zawC
WxkC1RMYp86sdFUSBYubopVGZHI4zVobOhanvnGZjFQDuJZsAdM+Bpg/IYE7An4A
R1MBHg5GQ/tLLdwLGugvmPh+0ZmrE2ykF95v9hX1AgMBAAGjggE7MIIBNzASBgNV
HRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAyBgNVHR8EKzApMCegJaAj
hiFodHRwOi8vdDEuc3ltY2IuY29tL1RoYXd0ZVBDQS5jcmwwLwYIKwYBBQUHAQEE
IzAhMB8GCCsGAQUFBzABhhNodHRwOi8vdDIuc3ltY2IuY29tMEEGA1UdIAQ6MDgw
NgYKYIZIAYb4RQEHNjAoMCYGCCsGAQUFBwIBFhpodHRwczovL3d3dy50aGF3dGUu
Y29tL2NwczApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRU3ltYW50ZWNQS0ktMS01
MzcwHQYDVR0OBBYEFMJPSFf80U+awF04fQ4F29kutVJgMB8GA1UdIwQYMBaAFHtb
Rc+vzst6/TGSGmq280brV0hQMA0GCSqGSIb3DQEBCwUAA4IBAQCNBt5DyXYCytkj
l17zY9d9RMIPawr1B+WLuPrgo/prgJK1AyzFN+DC5ZW1knAYKEKU7kt3agEPiyPs
Vk30AGnlhMji6t5bPvY8BzqUymwnscyDGmBxJ9K/AvUeRNNI1abTdiEAnPqYZOsX
Nj/rGzw+prHZWAYOctlovvGnINdS5KR3H3FwnVU1hTfhHU2UwnB/lUBuS32ytCkq
A3nIuUxnYQSgiyf/WQDrVX/GtzM1LV5OrLjqEsXo97mrvnSSLLfZTcqELxzC8HJ8
sjFuz4DliAc2UXu6Ya9tjSNbNKOVvKIxf/L157fo78S1JzLp955pxyvovrsMqufq
YBLqJop4
-----END CERTIFICATE-----

ROOT:

-----BEGIN CERTIFICATE-----
MIIERTCCA66gAwIBAgIQM2VQCHmtc+IwueAdDX+skTANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MTExNzAwMDAwMFoXDTIwMTIzMDIzNTk1OVow
gakxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwx0aGF3dGUsIEluYy4xKDAmBgNVBAsT
H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xODA2BgNVBAsTLyhjKSAy
MDA2IHRoYXd0ZSwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD
VQQDExZ0aGF3dGUgUHJpbWFyeSBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEArKDw+4BZ1JzHpM+doVlzCRBFDA0sbmjxbFtIaElZN/wLMxnC
d3/MEC2VNBzm600JpxzSuMmXNgK3idQkXwbAzESUlI0CYm/rWt0RjSiaXISQEHoN
vXRmL2o4oOLVVETrHQefB7pv7un9Tgsp9T6EoAHxnKv4HH6JpOih2HFlDaNRe+68
0iJgDblbnd+6/FFbC6+Ysuku6QToYofeK8jXTsFMZB7dz4dYukpPymgHHRydSsbV
L5HMfHFyHMXAZ+sy/cmSXJTahcCbv1N9Kwn0jJ2RH5dqUsveCTakd9h7h1BE1T5u
KWn7OUkmHgmlgHtALevoJ4XJ/mH9fuZ8lx3VnQIDAQABo4HCMIG/MA8GA1UdEwEB
/wQFMAMBAf8wOwYDVR0gBDQwMjAwBgRVHSAAMCgwJgYIKwYBBQUHAgEWGmh0dHBz
Oi8vd3d3LnRoYXd0ZS5jb20vY3BzMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU
e1tFz6/Oy3r9MZIaarbzRutXSFAwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL2Ny
bC50aGF3dGUuY29tL1RoYXd0ZVByZW1pdW1TZXJ2ZXJDQS5jcmwwDQYJKoZIhvcN
AQEFBQADgYEAhKhMyT4qvJrizI8LsiV3xGGJiWNa1KMVQNT7Xj+0Q+pjFytrmXSe
Cajd1FYVLnp5MV9jllMbNNkV6k9tcMq+9oKp7dqFd8x2HGqBCiHYQZl/Xi6Cweiq
95OBBaqStB+3msAHF/XLxrRMDtdW3HEgdDjWdMbWj2uvi42gbCkLYeA=
-----END CERTIFICATE-----

Thanks
Charan