Author here: if people aren't familiar with webcrypto (https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...) 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.
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.
> 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.
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.
I'm not aware of any large-scale A/B tests for this. That being said, I imagine if Amazon thinks OV is good enough for them, I think it's safe to say it won't affect conversion rates all that much.
Perhaps it would even have a negative impact, given that some browsers enforce OCSP for EV certificates, which could slow things down if the server or client does not support OCSP stapling. (Not sure if that combination - enforcing OCSP for EV but not supporting stapling - exists in a browser out there.)
> 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.
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?
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.
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.
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...
From what I understand, code signing certificates include special OIDs that flag them as usable for things like Authenticode. SSL/TLS certificates don't usually have these OIDs, so they would not be usable for that purpose.
I don't know for sure whether CertSimple offers code signing certificates as well, but some quick research makes me think they don't
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.