
CertSimple 5: DBA support, instant rekeying, flat pricing - alecmuffett
https://certsimple.com/blog/certsimple-v5-doing-business-as-ev-https
======
nailer
Author here: if people aren't familiar with webcrypto
([https://developer.mozilla.org/en-
US/docs/Web/API/Web_Crypto_...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Crypto_API)) it's a way to do real crypto, using the OS
and openssl / boringssl (Google's openssl fork). I.e., it's not 'JavaScript
crypto', but actually has proper randomness, hence properly unguessable keys.
When we make keypairs with webcrypto, the private key never leaves the
browser, so CertSimple doesn't know it.

That said, if a user prefers to make keys on their own machine we create a
custom bash / powershell script to create the necessary CSR and private key in
a single paste - no clicking, no Q and A, and without installing anything.

~~~
tptacek
WebCrypto is browser Javascript crypto. You cannot rely on it to allow
browsers to keep secrets from servers: the server has a variety of different
straightforward ways to compromise cryptosystems it feeds to browsers.

Randomness is far from the most important problem with browser Javascript
crypto; critics of browser crypto generally assumed that browser Javascript
would get secure randomness at some point. The most important problem with
this scheme is that there's no way to provide assurance that the browser JS
runtime is what the user of an application expects it to be.

WebCrypto was chartered as a way to recreate the DRM schemes that Flash video
plugins relied on, without needing plugins. You can read the working group
notes to see that. It was never intended as, and cannot function as, a way of
creating "server-proof" crypto apps.

~~~
nailer
> The most important problem with this scheme is that there's no way to
> provide assurance that the browser JS runtime is what the user of an
> application expects it to be.

That's correct. We only use the native runtime (ie, no shims) but obviously
users have to trust that that's the case unless they want to inspect the code.
If there's no working window.crypto (or for certain blacklisted platforms with
partial implementations) we go straight to out-of-browser keygen. Furthermore,
the user has to trust that we're not sending the private key back to us by
some channel: they could do this fairly easily by inspecting the code but if
they're uncomfortable it's easier to click the 'make keys on my server'
option.

------
koolba
Any stats on A/B testing at scale for EV certs v.s. non-EV? I'm sure it would
vary by industry but I'm curious if anyone has shown that it's statistically
worth it in their particular situation.

A pretty green bar with your company name is great and all but is it actually
worth it? It's not just the couple hundred dollar price tag of getting the EV
cert. It's the maintenance of having to manually replace it every N years v.s.
automating the deployment via something like LetsEncrypt.

~~~
nailer
The only studies are from a decade ago using the IE7 UI:

Then:

    
    
      https://paypal.com               Identified by Thawte
    

Compared to now:

    
    
      PayPal Inc [US] | https://paypal.com  
    

I'd love to either be able to do this ourselves or for the browsers to test
the effectiveness of their own UIs.

~~~
koolba
> I'd love to either be able to do this ourselves or for the browsers to test
> the effectiveness of their own UIs.

That'd be pretty cool. A flag you could set (probably in head > meta) that
instructs the browser to use a default padlock instead of a fancy EV name for
display HTTPS info. That'd obviate the need to have two separate HTTPS
endpoints for your app too. Combined with User-Agent verification you could
infer what % of clients respect the flag and what % impact (if any) it has on
their conversion habits.

Course I doubt browser vendors would be up for adding something like this.
Would probably be a pain as the rendering code would be separate from the
display of the overall chrome.

------
stephenr
It'd be nice if CertSimple had a LetsEncrypt (obviously with some kind of auth
- perhaps based on a secondary private/public key pair unrelated to the
certificate(s)?) style tool to allow issuing/renewing certificates for a known
account.

I understand that the initial proof of entity needs some human involvement on
our end, but surely once it's proved, renewals could be automated?

~~~
nailer
Automated issuance is on our roadmap and ACME/Certbot support is something
we'd like to do if possible. We still have some prequisites we need to sort
out first (like proper subscription billing) but the idea is solid. ACME would
be preferable over a custom automatic renewal mechanism since theoretically it
would allow existing clients to get and renew EV certs automatically but we'll
have to start actually hacking it to see.

You still need to reconfirm identity before the new cert is issued. E.g., we
have a lot of startups as customers and they often forget to pay a bill, and
are no longer an active entity according to their Secretary of State (we flag
this up before payment). So it wouldn't ever be entirely automated but that
doesn't meant we can't do automated renewal: ACME tries to renew repeatedly a
month before the cert expired and we can block until identity is reconfirmed.

~~~
stephenr
Do you have the specific steps/requirements for each country documented
somewhere?

~~~
nailer
The country, and TLD, and type-of-business (active registered company, DBA,
sole prop, onion), and other logic (detecting inconsistencies between data
sources, determining if whois privacy is in use, etc) are implemented and
documented in source code - CertSimple itself is an engine to meet those rules
and handle those exceptions.

The requirements for EV itself are in CABForum docs, see
[https://certsimple.com/blog/are-ev-ssl-certificates-worth-
it](https://certsimple.com/blog/are-ev-ssl-certificates-worth-it) for an
overview.

------
yazr
Can these EVs be used for binary/exe signing ? And what about individual
developers i.e. not a company

~~~
nailer
1\. We're totally focused on TLS certs right now - and we've got more things
around that we want to improve to fill our roadmap for the next six months.

2\. We generally focus on active, registered companies (since we can check
most of the details before payment) but we can (and have) done certs for
individual developers before, albeit not at the same speed as registered
companies - Troy Hunt / Have I Been Pwned used us last month, see
[https://www.troyhunt.com/journey-to-an-extended-
validation-c...](https://www.troyhunt.com/journey-to-an-extended-validation-
certificate/)

