CertSimple Blog

I don't currently see a 500 ms difference, so maybe they figured something out. From my shell, I see about 35 ms to http://www.stavros.io/404 and about 85 ms to https://www.stavros.io/404 (the HTTPS site serves actual content and the HTTP a redirect, which confounds the numbers).

The HTTPS server is currently offering me a 4096-bit-RSA certificate, signed by the 2048-bit-RSA StartCom class 1 intermediate CA. There's no security benefit in a 4096-bit cert signed by a 2048-bit one, since any attacker capable of breaking 2048-bit RSA but not 4096-bit is just going to attack the CA cert and sign their own forged cert (and any attacker sorta capable of breaking 2048-bit RSA will dedicate their brute force effort to CA certs). And to my knowledge, all current CA intermediate certs are 2048-bit. Meanwhile, because of math, 4096-bit certs take a lot longer to handshake: see e.g. https://certsimple.com/blog/measuring-ssl-rsa-keys

CertSimple's data indicates a 25 ms difference between 2048-bit and 4096-bit keys on their server, so I'd expect that the 4096-bit key is responsible for at least most of the performance difference here. A few years ago I screwed this up on a production shared web host, and I believe we saw a greater than 50 ms difference. (While we're at it, that cert is SHA-1, so it's possible they can get a reissue for free.)

Were you able to replicate the 500 ms (!) performance difference on your own server? Are you using a 2048-bit cert and reasonable cipher suites?

I think the only solution to fixing this is for Safari to show the domain again. It is the URL that is unique and known by the visitor, not the business name.

Here in the UK there is another problem with EV certs, there is no way of registering a "trading name" or "doing business as (DBA) name" against a company so you can only have an EV cert issues against your actual registered business name. If that is different from your trading name and what you use as your domain name then they are less than worthless. For example, if the company is "Widgets of London Limited" but trade online as "Widgets Online" with the domain "widgetsonline.com" they cant get an EV cert with "Widgets Online" as the name - even if they own the registered trademark of it.

See https://certsimple.com/help/doing-business-as-or-trading-names

Maybe another solution to this is not to show just business name directly, force it to show the domain as well unless there is a registered trademark that is proven to be owned by the organisation and only then go the safari route of showing a shortened name?

Hi Jonah,

I run https://certsimple.com. We only do EV certificates, and we do it much faster than any of the existing companies, which normally quote 7-10 days to complete the validation process. I waited around a month for GoDaddy earlier this year, which is how I ended up making CertSimple.

CertSimple do EV certificates in an average of 5 hours.

- We check the customers info against the required government information sources (as well as a number of other places) before customers pay us.

- After we take the order, we provide a specific set of instructions based on a number of characteristics of the customer's actual business to make the validation process as fast as possible.

- We have a real focus on UX: there's no software to install or command line questions, our validation UI updates live, and we manually follow up with every customer to iterate our product.

I'm mike@certsimple.com, or @mikemaccana on Twitter.

1) Strength - always at least 2048 bits, 4096 if speed isn't as critical as security. For your CSR make sure you use SHA256 for signing (http://itigloo.com/security/generate-an-openssl-certificate-request-with-sha-256-signature/)
As for ciphers, depends on the tradeoff you need for compatibility vs. security; I would consult Mozilla:
https://wiki.mozilla.org/Security/Server_Side_TLS
They also have a handy config generator, depending on what server you're going to use:
https://mozilla.github.io/server-side-tls/ssl-config-generator/

2) For lowest cost and no bullshit, I'd go with CertSimple (https://certsimple.com), or DigiCert (https://digicert.com).

3) As mentioned below, SSLLabs will point out if any of your config is risky. Besides that, you might want to add a 301 URL redirect to your web server to force people to only use SSL and avoid the fatal mistake of someone forgetting to type http_s_.

Have fun!

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit.

Not to be snarky, but haven't people written tools to help with this? This seems like a common issue. I mean, there's `sed` and similar tools, obviously, but something that could go, validate that the link works over https://, and update it. I don't see why that would need to be some monumental amount of work.

HTTPS is more than just privacy. See https://certsimple.com/blog/ssl-why-do-i-need-it and https://www.troyhunt.com/ssl-is-not-about-encryption/

> Brotli takes a lot longer to compress than Zlib

Only for the default settings, which for brotli is the maximum compression ratio and for nginx isn't, but brotli seems to win in general for comparable compression times or sizes: https://certsimple.com/blog/nginx-brotli

Anyway, compression times don't matter if you're compressing things up ahead. E.g. nginx can serve static files compressed with gzip_static / brotli_static. It's true that you might have to serve both, but disk is cheap and improving latency and response time is hard, so I have no problem with that tradeoff. Or you could just have the zlib encode on the fly for old IE, if space is truly a concern.