Qualys SSL Labs Weak or insecure signature

Server
1

Hello,

I’m trying to harden my server a bit. I have a Let’s Encrypt SSL certificate and I lease my virtual private server from GoDaddy. I use cPanel / WHM to manage it but I’m familiar with Linux and feel comfortable with the terminal. My server is running CentOS 6.8 Final.

I’m using Qualys SSL Labs website to check my SSL setup and I receive a message that I’d like to fix but I don’t really understand it. I’ve tried googling it but get a bit confused with people talking about chains and stuff like that. At the bottom of the Authentication window, in the Certification Paths section, I see this:

Path #1: Trusted
1	Sent by server	www.mydomain.com 
Fingerprint SHA1: 4eefac38a8fe99aa816b005a9849c674cd3998d6
Pin SHA256: Cf88k9H3r3pB9FtwRlWRlGnA108n5Jsv4S19zcAmrRo= 
RSA 2048 bits (e 65537)	/ SHA256withRSA
2	Sent by server	Let's Encrypt Authority X3 
Fingerprint SHA1: e6a3b45b062d509b3382282d196efe97d5956ccb
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg= 
RSA 2048 bits (e 65537)	/ SHA256withRSA
3	In trust store	DST Root CA X3   Self-signed	
Fingerprint SHA1: dac9024f54d8f6df94935fb1732638ca6ad77c13
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys= 
RSA 2048 bits (e 65537)	/ SHA1withRSA 
Weak or insecure signature, but no impact on root certificate

The part I’d like to fix is the part where it says Weak or insecure signature, but no impact on root certificate. Could someone help me understand this and provide suggestions on how I’d remove the weak or insecure signature and make it a strong one?

Thank you.

2

You can’t fix that, that’s the “root certificate” that the browser uses to verify your certificate, your server doesn’t send it, the client has it.

1 Like
3

Thank you. I will read up on the root certificate and see if I can make some heads and tails out of this. This stuff is a bit confusing. A lot of new terms to learn. Chain of trust, root certificates, root certificate authority, etc.

Thanks for the help!

4

I’ll try to give a bit more explanation. Don’t worry too much if you don’t follow everything and decide you don’t care, the tl;dr is that everything is fine.

SSL certificates are a bit like real world certificates, with a signature on them that proves the contents of the certificate (like who it was issued to and what for) are agreed by the signatory. Instead of being signed with a pen and a unique-ish squiggle by a human they’re signed using a cryptographic hash to turn the contents of the certificate into a number, and then public key cryptography to turn that number into a different number in a way that only someone who knew the associated private key could do, but anyone with the right public key can verify. Public key cryptography is a whole separate subject but you can find Wikipedia article or Youtube videos explaining RSA, the type of public key cryptography you’re using in this case.

But individual SSL certificates still leave you with a problem, you know somebody signed this certificate, but how do you know whether to trust them ? More certificates! Your certificate for www.example.com is issued by Let’s Encrypt, and then Let’s Encrypt has a certificate (which is included in that chain.pem and fullchain.pem if you examined the files on your server) and that proves it was authorised by DST Root CA X3 to issue certificates to other people. This is a different kind of certificate (you can’t use your www.example.com certificate to issue more certificates, just like my 100 metres swimming certificate doesn’t authorise me to drive a bus) but it too is signed in the same way.

It still leaves us with the problem of how we trust DST Root CA X3 in the first place. The diagnostic says “in trust store” and indeed in either an operating system like Windows or Mac OS X, or in a web browser like Firefox, there is a “trust store” which is a collection of certificates, the subjects of those certificates will be trusted by the OS or browser. These are called “roots” because they are at the root of an imaginary tree in which your certificate for www.example.com is one of the leaves.

OK, now, “weak or insecure signature” refers to the line above where it says “SHA1withRSA” and you’ll see the earlier ones all said “SHA256withRSA”. I said signatures are made with a hash algorithm combined with a public key algorithm, and this means the DST Root CA X3 certificate was signed using the SHA1 hash, whereas the others used SHA256. SHA1 is a rather old hash, and experts suspect that it will soon be “broken” affordably, that is, a criminal or government with some money will be able to create things that hash to the same value, which would in turn (if not for countermeasures) mean they could forge working certificates.

So to stay a step ahead, the operating system and browser vendors, “trust store operators” have decided no-one shall use SHA1 to make more certificates and their operating systems (and browsers) will stop trusting the SHA1 signatures on certificates next year.

BUT, the DST Root CA X3 isn’t a certificate they need to trust - they baked it into their operating system or browser as part of the trust store, they know it’s authentic and not forged because they put it there. So this certificate is exempt from the rule, and that’s why it says “but no impact on root certificate” in the diagnostic from SSL Labs.

The root keys don’t “really” need to be inside a certificate at all. But the software processing them deals with a lot of certificates already, and keys aren’t just a single number like “5” they need other information in some format with them, so everybody just transports them as “self-signed certificates” even though we don’t really need them to be signed.

4 Likes
5

I understand some of this. I know a little bit about cryptography. For example, I know there’s a lot of collisions in the MD5 cryptographic hash function and this is why we shouldn’t be using MD5. I can understand why we shouldn’t be using SHA1. Even if it’s not “breakable” yet, Moore’s law seems to still hold true. What might take a million years to break now might take 47 days in 5 years from now. It’d make sense that some smart people might just collect SHA1 encrypted data and just hold on to it until the technology arrives that allow them to break that encryption.

So, I really want to wrap my head around all of this. I have an SSL certificate for my site. Let’s Encrypt Authority X3 signed the certificate but devices don’t really trust Let’s Encrypt Authority X3 at first…so Let’s Encrypt Authority X3 must find someone else to sign the certificate. From what I’ve been reading, right now, this is IdenTrust.

Let’s see if I have this right so far. An intermediate CA is just a CA we don’t trust yet. An intermediate CA will just point to either another intermediate CA or a root CA. Once it points to the root CA, there’s no more to point too, because that’s the first in the chain. Eventually, everything will point to a root CA and if it’s not trusted, then we get an error on the device…right? For Let’s Encrypt, the root CA is ISRG Root X1, right?

Self-signed certificates…will they be root CA’s that just aren’t trusted?

I’m looking at chain.pem and fullchain.pem. chain.pem just has one block of ascii characters. Is that the cryptographic hash? And that just shows who signed my certificate, right? Then there’s fullchain.pem and that has two blocks. One is the same as what’s in chain.pem, which makes sense, then the other one, that’d be IdenTrust or would that be ISRG Root X1.

Thanks.

6

Looks like I’m not quite right. It looks like fullchain.pem is just my cert.pem file and chain.pem file.

So those values are cryptographic hashes (encrypted data), right?

Let’s see if I got it right now…

privkey.pem: My private key that should never be shared.
cert.pem: The SSL certificate for my server.
chain.pem - The intermediate CA(s). In this case, just IdenTrust?
fullchain.pem - My SSL certificate for my server and the intermediate CA(s).

Is that right now?

7

No, they are PEM encoded x.509 certs. These do include a signed hash, but there's a lot more than just that.

Not quite, the intermediate is Let's Encrypt Authority X3 (signed by DST Root CA X3 owned by IdenTrust

1 Like
8

Right. Let's Encrypt also has its own root certificate, but it's not trusted by the major browsers yet.

Not exactly. Intermediates are usually more short-lived than root certificates in the trust stores. Intermediates can be more short-lived, because the root can just issue a new intermediate. However, the roots can't be replaced easily, because root trust stores aren't updated frequently and to become trusted by all major and minor clients, a root has to be included / updated in all of them.

The main reason to have intermediates is that they enable the CA to keep the private key of the root certificate offline, which prevents exposing it should any vulnerability occur. Intermediate keys are still needed online, so the leaf certificates can be signed, but if one of them is ever compromised, the intermediate can be replaced by a new intermediate signed by the same root. In that case, not all trust stores have to be updated.

9

No. Encryption and hashing are separate things. Encrypted payloads are usually decryptable. Either using the same key (symmetric encryption) or using the private key corresponding to the public key used for encryption (asymmetric encryption).

Hashes shorten longer payloads to a fixed short size. Cryptographic collisions in particular make it hard to find collisions, so two payloads ending up being the same hash value.

Certificates use even another cryptographic feature called signing. Signatures ensure a certain party created / signed a payload. So in the case of certificates, a CA signs a certificate and says: We checked that the owner of the corresponding private key controls the domains listed in Subject Alternative Name / Common Name.

1 Like
10

Okay, so they're the actual certificates but are PEM encoded x.509 that include a hash.

Okay. So, chain.pem includes the Let's Encrypt Authority X3 PEM encoded x.509 certificate? The chain.pem file shows that it's signed by DST Root CA X3 and our computers show that this is owned by IdenTrust? Our computers also know about DST Root CA X3 and in order for the certificates to be valid, there's something in chain.pem or fullchain.pem that has to match something in our PCs store, right?

11

And this is why they're cross signed then, right? Because the root certificate isn't trusted by major browsers yet but IdenTrust is. I think I'm starting to understand.

Okay. This makes sense. What exactly are in the stores though? Actual certificates or something else? My browser connects to my server, via the secure hypertext transport protocol and Apache provides three files? cert.pem, chain.pem and fullchain.pem, right? What's the private key for that's stored on the server? I'm trying to find a diagram that shows the whole process. That might make it a little easier for me to understand.

12

Yes, the Issuer field (and Certificate Authority Key Identifier extension) identify which CA signed it. So your cert says Let's Encrypt Authority X3 and that one says DST Root CA X3. As a root cert trusted by your browser or OS has been reached then your cert can be considered trusted if there are no problems with the chain (e.g. exceeding any .

1 Like
13

Exactly.

Yes, certificates, usually self-signed. Sometimes signed by another previous root certificate as an alternative to the cross-signing process to cover the period of inclusion.

Usually either cert.pem + chain.pem OR fullchain.pem, as the first two concatenated are exactly the latter. Your private key is stored in privkey.pem.

1 Like
14

Okay. Thank you for clarifying that. What's preventing me from pretending I'm the certain party? That'd be the store, right? I could pretend that I'm IdenTrust and sign a certificate but the data in the store won't match and the browser will say hey, you're not really IdenTrust, right? Is this how man-in-the-middle attacks work?

I know the gist behind them. If we're trying to connect to some place like https://www.example.com through a switch and I'm on that switch and the traffic passes by me, I could flood the switch to turn it into a hub, put my NIC in promiscious mode so it sees the traffic, setup a DNS server and pretend I'm example.com. You'd connect to my server instead of the real example.com, I'd connect to the real example.com and be able to decrypt the information.

I tried experimenting with this a few years back. And it worked, but my browser would display an X across the https sign. It knew that I wasn't connect to the real destination but I was successfully able to view the encrypted text in plain text. I wasn't trying to do anything bad, I was just trying to learn how stuff worked. It was a neat experiment, seeing encrypted text in plain text.

15

I found a site that explains the whole concept for me and it makes sense. Thank you guys for taking the time to answer all my questions. This is what the site says:

  1. A browser requests a secure page (usually https://).

  2. The web server sends its public key with its certificate.

  3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.

  4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.

  5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.

  6. The web server sends back the requested html document and http data encrypted with the symmetric key.

  7. The browser decrypts the http data and html document using the symmetric key and displays the information.

Now, I have to try and figure out the various ciphers and protocols. Using Qualys SSL Labs site, I’m now getting a score of A. I managed to enable Forward Secrecy. I’m not 100% sure if it’s Perfect Forward Secrecy or just Forward Secrecy yet or not. I’d like to get an A+ score though. Perhaps those questions about ciphers and protocols are best left for the Apache mailing list though, as they don’t relate to the Let’s Encrypt certificates so much as they do configuring Apache.

One more question though. I’m using RSA encryption, right? 2048 bits. I’ve noticed some sites use 4096 bits. To me, it’d make sense to be using 4096 bit keys. Shouldn’t I be using Let’s Encrypt to generate 4096 bit keys instead of 2048? Thanks!

16

It depends. 2048 is considered a good value for right now, as it's strong enough to prevent reasonable attacks. You can certainly set certbot to use 4096 bit keys. Keep in mind that the longer the key, the more load it places on the CPU when using that keypair.

1 Like
17

They're the same thing, it's just that some people don't like using the word perfect because you can't really know that it is.

The only difference between A and A+ is if you're using HSTS with a sufficient duration (over 6 months).

1 Like
18

You don't know the private key used to sign the certificates. And if you don't know it, it's near to impossible to forge a signature that verifies with the corresponding public key.

1 Like
19

How much load are we talking you think? Right now, I don't really have a site, just a server. I have a very simple message saying future site of blah. Even when I get the site completely setup, I don't expect a huge amount of traffic.

I'm more worried about the future. I can't find the article, but recently, I came across an article. It talked about how this person broke some sort of encryption in something like 47 days. When the encryption was created, it would have taken a PC a million years or so to break it. Because of him breaking it, there was something like the SETI@Home stuff created to break all this older encryption or something using a bunch of PCs on the net and in the end, the project decrypted something like over 400 previously unbreakable encrypted stuff. That might not be 100% correct, but that's how I remember it. Even though RSA 2048 is fairly safe now, I worry a lot about the future. I guess I'm being paranoid because in all reality, what would my server have that would be interesting to someone? RSA 4096 has been successfully decrypted, recently, using high powered microphones and listening to the noises from the CPU.

I guess what it comes down to is how secure do I want to be. It seems there's always going to be pro's and con's. Better encryption, more CPU usage, stronger ciphers, less users who can view my site, etc. I just gotta find the right combination I guess that gives me strong security but still allows the majority of the people out there to view my site.

Thanks for helping explain all this to me guys! I really appreciate it!!!

20

This is something that I want. If I understand it correctly, HTTP Strict Transport Security (HSTS) makes it so users can only connect to my server via HTTPS. I have tried setting this up the best I could. I used mod rewrite rules, because I wanted everyone to use https since I got the SSL certs now. If someone goes to the unsecure website, it redirects them. I was thinking though, maybe I can just tell Apache not to listen on port 80 at all and if people go to http://mydomain.com, their browser will be smart enough to take them to the secure version? I'll look into this more. Thanks for bringing this HSTS to my attention. I didn't know about it before.