4 ms·

A question I'm facing with SSL that wasn't satisfied by the article: What SSL vendor has the shortest certificate chain? I'm looking to optimize SSL handshake

A question I'm facing with SSL that wasn't satisfied by the article: What SSL vendor has the shortest certificate chain? I'm looking to optimize SSL handshakes and outbound traffic in general from Cronitor's telemetry API and shrinking that certificate chain will make a big impact, but I couldn't find a comparison between vendors. I did some sampling, downloading cert chains, but it was far from exhaustive.

toast0 6y ago
Down to the byte level, I'm not sure, but if you can get an all ECC chain (or as much ECC as you can get, gorkish points out below that all ECC isn't practical), those certs are gobs shorter than RSA certs, because the public keys are shorter. Otherwise, any CA that's been around for long enough should be able to give you a cert signed by an intermediate signed by their trusted root; so you would just send clients your cert and the single intermediate cert. You should only have a chain longer than two certs if you need to cross chain to another root; but so many of the older clients that needed really old CAs were forced off of PKI because they don't support SHA256 signatures.
- ngz00 6y ago
  Would you explain what you mean by "cross chain to another root"?
  - Macha 6y ago
    If you set up a new CA, you're not immediately in browser roots until you can prove you're running your CA in a responsible fashion. It's usually easier to pay an existing CA to sign your root cert as if it was one of their own intermediates, and follow their rules to get established before tackling getting approval in browsers. Even after you're approved, you need to wait for users to upgrade to new browsers/OSes/devices (depending on use case) to have your cert included in their trust store. This even applies if you are the browser vendors, Lets Encrypt was cross signed for the first year or so of its existence.
  - toast0 6y ago
    So, just because I'm more familiar with DigiCert, and it's more clear with specific names. Let's say you had a certificate for CN=example.org, issued by DigiCert ECC Secure Server CA, the certificate of which is itself is issued by DigiCert Global Root CA Most clients have that CA in their chain, so you can send the example.org cert, and the DigiCert ECC Secure Server CA cert, and have very good compatibility. DigiCert Global Root CA was created November 2006, and maybe your client has a CA bundle from before then, or anyway doesn't have that CA. Not to worry, DigiCert has a cross signed copy of DigiCert GLobal Root CA, issued by Baltimore CyberTrust Root. Baltimore CyberTrust Root was created in May 2000, and most people like them. So, to support that small fraction of users which have Baltimore CyberTrust Root and not Digicert Global Root CA, you can send CN=example.org, the normal DigiCert ECC Secure Server CA, and the cross signed Digicert Global Root CA, issued by Baltimore CyberTrust Root. Now, DigiCert happens to own the CA key for Baltimore CyberTrust Root, so they also can issue certs from a new intermediate they generated signed by it, but they were using their cross-signed Root as an option for compatibility with legacy clients before they purchased the CA. Sending the three certs should also work for well behaved clients that have the DigiCert Global Root CA, but not Baltimore CyberTrust Root; although not all clients will properly validate when they trust a CA in the chain, but not the last CA in the chain. I'm not affiliated with DigiCert, I was worked for a customer, and was in charge of selecting the CA while we supported a lot of ancient phones, each with their own mess of CA bundles, very few of which were documented. :( DigiCert helpfully links their cross signed certs here https://www.digicert.com/digicert-root-certificates.htm#cross-signed https://www.digicert.com/digicert-root-certificates.htm#cros...
    - ngz00 6y ago
      Great explanation, thank you!
- shanemhansen 6y ago
  In all likelihood, what matters is of you're going to overflow a packet boundary when the server presents certs.
  - toast0 6y ago
    A quick check on ssl labs says a site I'm familiar with sends 2717 bytes of certificate matter with an ECC entity certifcate, and 2921 bytes with an RSA entity certificate. The intermediate is the same for either chain, and it doesn't send the root. 204 bytes is not that much, and I'd have to run packet captures to check how much other data is going into a TLS handshake, but that seems like it is going to be throwing an extra packet in for some people, depending on their effective MSS. This particular certificate has 7 Subject Altnerative Names, the difference for a smaller certificate would be a larger portion of the handshake data.
- gorkish 6y ago
  This question is on my wavelength. Getting an all-ECC chain EV cert that is published to the CT logs is dang near impossible. I spent a couple of months of back and forth with DigiCert over the last 2.5 years or so trying to get one, but they were never able to issue one despite trying and having the correct roots and intermediates in place to do this. I feel this is one of those situations where their software simply couldn't handle this edge case, and I was not important enough to escalate to a manual process. The benefit to an all ECC chain (including an ECC root) is not just size. There is a some small amount of time and energy especially on mobile devices on first load when validating ECC signatures compared to RSA 4096 signatures of the intermediate and client cert (the signatures are bigger too). Granted, it is cached after that, but collectively if I have 10 million sessions per month that's real time and energy wasted.
cuu508 6y ago
Not an expert, but I've assumed as long as the certificate(s) fit in a TCP packet the precise size doesn't matter too much. Your certificate + intermediary + root (3 total) seems reasonable. A related thing to look into, if you are not using it already, is ECDSA certificates. They are a little smaller than RSA, but, more importantly, they are easier on the CPU -- more handshakes per second.
- encoderer 6y ago
  Hey Peteris, thank you for the reply, hope things are well. One thing we found is that sometimes clients on a VPN have a smaller max packet size, causing SSL connections to fail, but it's not a main thing we're trying to solve. Primarily it's bandwidth and speed.
  - toast0 6y ago
    > sometimes clients on a VPN have a smaller max packet size This sounds like a path MTU problem. There's a couple ways to solve this. -1) Make sure you're not dropping icmp needs frag packets. 0) Ignore it --- it's not really your problem, and it's 2020, people shouldn't screw up MTU like it's 1997 anymore. This is easy, but not very effective. 1) clamp your outgoing MTU to 1480. A lot of big sites do this, and it avoids problems in most of the broken networks, but you're adding overhead. But it's pretty easy to do. Doing it so you send lower MSS back to the client helps with large packets they send you. 2) Clamp effective MTU to whatever the other side told you in the TCP SYN - 20 (or whatever value you like). This isn't easy, but it fixes a lot more networks. 3) Like 2, but targetted to only networks were you detect path issues. This would be a lot of work, but very effective. (I haven't been able to convince people to do this, but I've seen packet traces that show it would work). You could also try to reach out to the most broken networks, and change the world for the better. 4) Your OS almost certainly has path MTU blackhole detection, but it might not be enabled, or it might not be very fast acting. Check if you can enable it with a fast timeout. (To the thread; sorry, this isn't related to the article at all)
- toast0 6y ago
  Don't send the root unless you have a good reason (like supporting a dumb client, or a dumb platform). If the client trusts that root, they don't need a new copy. If the client doesn't trust the root, sending it won't help them trust it.
richm44 6y ago
If you care about performance then you should start by reading High Performance Browser Networking (the text is available online here https://hpbn.co/ https://hpbn.co/ ).
axaxs 6y ago
It depends on what you want to support. Browsers for example have been adding intermediates to their cert stores, so if you only want to support known new browsers, you only need to send the server certificate and nothing else...assuming said intermediate signed is one of the certs the browser has supplied.

toast0 6y ago

Down to the byte level, I'm not sure, but if you can get an all ECC chain (or as much ECC as you can get, gorkish points out below that all ECC isn't practical), those certs are gobs shorter than RSA certs, because the public keys are shorter. Otherwise, any CA that's been around for long enough should be able to give you a cert signed by an intermediate signed by their trusted root; so you would just send clients your cert and the single intermediate cert. You should only have a chain longer than two certs if you need to cross chain to another root; but so many of the older clients that needed really old CAs were forced off of PKI because they don't support SHA256 signatures.

ngz00 6y ago
Would you explain what you mean by "cross chain to another root"?
- Macha 6y ago
  If you set up a new CA, you're not immediately in browser roots until you can prove you're running your CA in a responsible fashion. It's usually easier to pay an existing CA to sign your root cert as if it was one of their own intermediates, and follow their rules to get established before tackling getting approval in browsers. Even after you're approved, you need to wait for users to upgrade to new browsers/OSes/devices (depending on use case) to have your cert included in their trust store. This even applies if you are the browser vendors, Lets Encrypt was cross signed for the first year or so of its existence.
- toast0 6y ago
  So, just because I'm more familiar with DigiCert, and it's more clear with specific names. Let's say you had a certificate for CN=example.org, issued by DigiCert ECC Secure Server CA, the certificate of which is itself is issued by DigiCert Global Root CA Most clients have that CA in their chain, so you can send the example.org cert, and the DigiCert ECC Secure Server CA cert, and have very good compatibility. DigiCert Global Root CA was created November 2006, and maybe your client has a CA bundle from before then, or anyway doesn't have that CA. Not to worry, DigiCert has a cross signed copy of DigiCert GLobal Root CA, issued by Baltimore CyberTrust Root. Baltimore CyberTrust Root was created in May 2000, and most people like them. So, to support that small fraction of users which have Baltimore CyberTrust Root and not Digicert Global Root CA, you can send CN=example.org, the normal DigiCert ECC Secure Server CA, and the cross signed Digicert Global Root CA, issued by Baltimore CyberTrust Root. Now, DigiCert happens to own the CA key for Baltimore CyberTrust Root, so they also can issue certs from a new intermediate they generated signed by it, but they were using their cross-signed Root as an option for compatibility with legacy clients before they purchased the CA. Sending the three certs should also work for well behaved clients that have the DigiCert Global Root CA, but not Baltimore CyberTrust Root; although not all clients will properly validate when they trust a CA in the chain, but not the last CA in the chain. I'm not affiliated with DigiCert, I was worked for a customer, and was in charge of selecting the CA while we supported a lot of ancient phones, each with their own mess of CA bundles, very few of which were documented. :( DigiCert helpfully links their cross signed certs here https://www.digicert.com/digicert-root-certificates.htm#cross-signed https://www.digicert.com/digicert-root-certificates.htm#cros...
  - ngz00 6y ago
    Great explanation, thank you!
shanemhansen 6y ago
In all likelihood, what matters is of you're going to overflow a packet boundary when the server presents certs.
- toast0 6y ago
  A quick check on ssl labs says a site I'm familiar with sends 2717 bytes of certificate matter with an ECC entity certifcate, and 2921 bytes with an RSA entity certificate. The intermediate is the same for either chain, and it doesn't send the root. 204 bytes is not that much, and I'd have to run packet captures to check how much other data is going into a TLS handshake, but that seems like it is going to be throwing an extra packet in for some people, depending on their effective MSS. This particular certificate has 7 Subject Altnerative Names, the difference for a smaller certificate would be a larger portion of the handshake data.
gorkish 6y ago
This question is on my wavelength. Getting an all-ECC chain EV cert that is published to the CT logs is dang near impossible. I spent a couple of months of back and forth with DigiCert over the last 2.5 years or so trying to get one, but they were never able to issue one despite trying and having the correct roots and intermediates in place to do this. I feel this is one of those situations where their software simply couldn't handle this edge case, and I was not important enough to escalate to a manual process. The benefit to an all ECC chain (including an ECC root) is not just size. There is a some small amount of time and energy especially on mobile devices on first load when validating ECC signatures compared to RSA 4096 signatures of the intermediate and client cert (the signatures are bigger too). Granted, it is cached after that, but collectively if I have 10 million sessions per month that's real time and energy wasted.

cuu508 6y ago

Not an expert, but I've assumed as long as the certificate(s) fit in a TCP packet the precise size doesn't matter too much. Your certificate + intermediary + root (3 total) seems reasonable. A related thing to look into, if you are not using it already, is ECDSA certificates. They are a little smaller than RSA, but, more importantly, they are easier on the CPU -- more handshakes per second.

encoderer 6y ago
Hey Peteris, thank you for the reply, hope things are well. One thing we found is that sometimes clients on a VPN have a smaller max packet size, causing SSL connections to fail, but it's not a main thing we're trying to solve. Primarily it's bandwidth and speed.
- toast0 6y ago
  > sometimes clients on a VPN have a smaller max packet size This sounds like a path MTU problem. There's a couple ways to solve this. -1) Make sure you're not dropping icmp needs frag packets. 0) Ignore it --- it's not really your problem, and it's 2020, people shouldn't screw up MTU like it's 1997 anymore. This is easy, but not very effective. 1) clamp your outgoing MTU to 1480. A lot of big sites do this, and it avoids problems in most of the broken networks, but you're adding overhead. But it's pretty easy to do. Doing it so you send lower MSS back to the client helps with large packets they send you. 2) Clamp effective MTU to whatever the other side told you in the TCP SYN - 20 (or whatever value you like). This isn't easy, but it fixes a lot more networks. 3) Like 2, but targetted to only networks were you detect path issues. This would be a lot of work, but very effective. (I haven't been able to convince people to do this, but I've seen packet traces that show it would work). You could also try to reach out to the most broken networks, and change the world for the better. 4) Your OS almost certainly has path MTU blackhole detection, but it might not be enabled, or it might not be very fast acting. Check if you can enable it with a fast timeout. (To the thread; sorry, this isn't related to the article at all)
toast0 6y ago
Don't send the root unless you have a good reason (like supporting a dumb client, or a dumb platform). If the client trusts that root, they don't need a new copy. If the client doesn't trust the root, sending it won't help them trust it.

richm44 6y ago

If you care about performance then you should start by reading High Performance Browser Networking (the text is available online here https://hpbn.co/ https://hpbn.co/ ).

axaxs 6y ago

It depends on what you want to support. Browsers for example have been adding intermediates to their cert stores, so if you only want to support known new browsers, you only need to send the server certificate and nothing else...assuming said intermediate signed is one of the certs the browser has supplied.