AlwaysOnSSL is a new free and automated certificated authority. While we already have LetsEncrypt, a free, automated and open, it is great to have more and more certificate authorities helping to make web site security accessible to everyone because there are no excuses to not use HTTPS.

AlwaysOnSSL is from CertCenter, a company selling Symantec and Digicert certificate among other products. CertCenter is from the university town Gießen, Germany but they have presence in the US as well, according to their web site and Twitter profiles. Symantec was accused of several misissuances and sold the business to Digicert. The certificates you can get from CertCenter chain up to DigiCert, so certificates will not have any problems with their trust in major browsers.

I tried to contact CertCenter to get API access to AlwaysOnSSL, but did not receive any communication back from them for the past 5 days. However, they have a nice and simple web UI to request, validate and issue certificates right from your browser. This review is based on what I could try from their web UI and API calls without access to the main AlwaysOnSSL product, but I had access to other functionality such as CSR validation.

Getting a certificate

In addition to their JSON REST API (look at those abbreviations!), it is possible to get a certificate directly from their web site. LetsEncrypt does not offer such UI by themselves, but there are options available (1, 2). One thing I noticed is that there is an option to generate a private key from the UI itself. The LetsEncrypt browser applications generate the private keys client-side without sending the keys to a remote server. However, for AlwaysOnSSL, the private key is generated on their servers. It goes without saying that this beats the purpose of a private key which should be, well, private.

There is an option to upload a Certificate Signing Request (CSR) too, which AlwaysOnSSL only added a few days back.

Validation methods

Just like any other CA, you must prove that you own/control the domain you are requesting a certificate for.

There are two validation methods available:

DNS validation: Enter the TXT record for the domain as mentioned. File upload validation: Upload the given file to the specified location.

I'm not going any detail in here because both validation methods come with simple and clear instructions.

Issued certificate

Once you have correctly submitted the proof, you can get the signed certificate. The whole process took me less than a couple minutes, and I must say, it was very straight forward and simple. I suppose the goal of AlwaysOnSSL is to make the process as easy as possible.

You can check your issued certificates and download private key (for next 3 hours) and the certificates.

Before getting into comparison, let me explain a few things in which you might not be familiar.

Certificate validity period

Personally, I would like to keep the certificate validity as short as possible. This helps to reduce the damage a private key exposure can do. It is easy to automate a certificate renewal, and with enough time buffer, you can tolerate temporary issues in CA servers and retry later too. This is the ideal approach, but the world we live in isn't really that perfect.

I hate shared hosts with a passion. One reason is that shared hosts have a steep price if you purchase SSL certificates from themselves, and charge money to install a certificate (around $10). Renewals cost as much as the initial installation cost. It only requires toddler-level math to see that shared hosts turn out more expensive than a VPS, but there are thousands of shared host users paying for this. For shared hosts, a longer validity period means they shell out less to install and renew certificates.

Certificate Transparency

Certificate Transparency is a great way to detect rogue Certificate Authorities from issuing certificates that they shouldn't have. You can read more about it from the linked site. It is basically an append-only log that CAs log every certificate they issue, and browsers can be informed about this log entry from the certificate itself, certificate status queries (OCSP), or during the TLS handshake.

Ideally, the CA should embed this log entry information (known as Signed Certificate Timestamp or SCT). If the certificate itself carries the SCT, the better because web server and client can verify without any additional requests.

Elliptic Curve Cryptography

ECC is a new alternative to the traditional RSA certificates. ECC private keys are smaller, but offer the same level of cryptographic strength of an RSA private key. For example, the cryptographic strength of a 2048-bit RSA key (~112 bits symmetric key) can be achieved with only a 224-bit EC key. In addition to the smaller key size, ECC certificates can perform faster. A quick benchmark I made on a small PC (Single-core Intel 2.2GHz):

sign verify sign/s verify/s

rsa 2048 bits 0.000838s 0.000038s 1193.4 26376.5

224 bit ecdsa (nistp224) 0.0001s 0.0002s 10785.4 5085.8

Lack of ECC certificates does not mean you will lose Perfect Forward Secrecy. However, it is nice to have ECC support, and possibly ECC intermediate and root certificates too, for the shorter key size and performance.

OCSP Must-Staple

Online Certificate Status Protocol is used to check with the issuing CA if the certificate is still valid. This requires a network request to the CA for every TLS handshake unless the response is cached for the time specified in the response. Because not every OCSP responder works fast enough or working to begin with, browsers soft-fail OCSP queries. OCSP Must-Staple is an x509v3 extension that basically marks the certificate that OCSP requests must be fulfilled. This comes with the risk of site being unreachable if the OCSP responder is offline or the server failed to staple OCSP response. You can easily shoot yourself in the foot with this, but if you require to make browsers not ignore OCSP failures, you can request a certificate with Must-Staple flag set. It is a nice to have feature if your CA can set Must-Staple flag in certificates just in case you need so.

Certificate trust

Browser and Operating System trust in the Certificate Authority is the biggest deal of all. If your CA's root certificate must be trusted in every browser/OS for your certificate to work. If your certificate chains up to a well-known CA, the better.

With those said, let's see how AlwaysOnSSL compares vs LetsEncrypt.

AlwaysOnSSL vs LetsEncrypt

LetsEncrypt AlwaysOnSSL Root certificate ISRG, cross-signed by IdenTrust

DST root CA X3 DigiCert Inc

DigiCert Global Root G2 Root certificate trusted ✔ (IdenTrust cross-signed) ✔ Certificate validity 3 months 6 months

12 months if you use your own CSR Certificate Transparency SCT embedded in certificate ✖ ✔ ECC Certificate support ✔ ✖ (CSR validation endpoint successfully detected ECC CSRs) ECC Intermediate certificate ✖, but coming soon ✖ ECC root certificate ✖ ✖ Wildcard certificates ✖, but coming soon ✖ OCSP Must-Staple ✔ ✖ Rate limits 20 certificates per registered domain per week

100 names per SAN certificate

Renewals exempt Unknown API ✔. ACME protocol is a standardized and open protocol ? REST API, but does not implement ACME protocol Integration libraries Many Minimal wrappers for PHP, Python and Go

Final words

Will I use AlwaysOnSSL

I do not use any shared hosts, and have automated all my TLS certificate issuing process. I choose ECC certificate support and like LetsEncrypt's mission on encrypting the entire web. I do not plan to use AlwaysOnSSL for myself. The fact that AlwaysOnSSL-issued certificates are from DigiCert and SCT embedding are great motivators though.

Is AlwaysOnSSL good enough for shared hosts

Absolutely! If you find renewing your LetsEncrypt-issued certificates daunting and manual task, AlwaysOnSSL is a great solution.

Future of AlwaysOnSSL

There are several client tools available for LetsEncrypt and many hosting providers have included LetsEncrypt. LetsEncrypt is not the first free (as free beer) CA, but it is the first to introduce the automation part. If AlwaysOnSSL were to support ACME-standard, I think AlwaysOnSSL will hit off because there is nothing much to change in existing LetsEncrypt/ACME clients.