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.
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.
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.
The last line just says, "We'll handle". Looks like it's truncated.
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.
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.)
Then:
https://paypal.com Identified by Thawte
PayPal Inc [US] | https://paypal.com
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.
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?
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.
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...
I don't know for sure whether CertSimple offers code signing certificates as well, but some quick research makes me think they don't