This being Amazon AWS gives me hope that this will be a CA with an API that allows automatic certificate issuance for domains you control. I find the process of issuing and reissuing certificates for all sorts of services to be an increasing amount of work as more and more services move to https.
(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)
Not a bad price, very much one I'd be willing to pay in order to get certificates via a CLI.
> or $149.95/year for unlimited sub-domains.
Ouch, 10x for a wild card? Why do issuers do this? It really puts a crimp on the whole "hobbyist doing hobbyist things" since that's $150/year just to not have cert errors on a single domain.
(FWIW, I'm deliberately excluding StartSSL for a variety of reasons.)
The cynic in me presumes that it's to make up for the lost cash in charging you individually for all those subdomains.
What do you mean about cert errors on a single domain [requiring a wildcard]? Because you use a lot of subdomains, or the bare domain/www. prefix?
If it's the latter, I think some (many?) registrars may let you add one or more SubjectAltName[1] values to a single cert for free or minimal cost, at least compared to a wildcard.
Not sure why you've been downvoted - this is pretty much the reason for elevated pricing of wildcard certs. They are more open to abuse (have seen them used for phishing sites), so the issuer carries a higher risk of having to do additional management around the cert (i.e. revocations), so therefore charge more.
maybe sslmate can make a deal with GlobalSign/AlphaSSL for wildcard DV certificates. At least there are resellers out there that offer wildcards for 42$ https://www.ssl2buy.com/alphassl-wildcard.php but of course suck at API/automation. I've seen other resellers (usually lowendtalk-VPS) selling AlphaSSL wildcards for below 40$/y in the past.
Let's Encrypt is nice for your web server, but using that certificate at the ELB may not be so trivial. I hope that Amazon will offer free SSL certificates for ELB. Their custom SSL certificates for CloudFront currently cost the outrageous $600/month (well, $20/day), and recently they added free SNI certificates, so, for CloudFront, they still may charge us, but, hopefully, a lot less than the crazy $600!
Nearly every CA already has an API to do cheap/free level (DV) SSL certificates for domains you control - all you need is one of:
- an admin-looking email address
- email mention in whois
- ability to upload a file
- ability to add a DNS TXT record.
Yes, that's a fairly low bar, that's why live.com gets taken over every few years with the same fake-DV-cert attack. This is also why EV certificates exist. Disclaimer: https://certsimple.com, where I work, sells EV certificates, we specifically don't sell DV certs.
Unfortunately I don't think that the level of differentiation provided in current browser implementations to EV certificates has users noticing when they get one.
I'd consider myself relatively security-savvy and I honestly couldn't tell you which of the sites I visit uses EV certs, and I'm fairly sure I wouldn't notice the browser bar change from green if a site got MITM'd with a valid DV cert after having an EV cert.
Pinning obviously helps in that case but AFAIK that works just as well for DV certs as EV.
Certly (which I founded) is working on an API for doing exactly this. You'll have to write your own tool to query our API (for now), but who knows what'll happen in the future.
More than that, the Mozilla request also mentions code signing certs, makes it clear this is not just an internal AWS thing:
Customers of the Amazon PKI are the general public. We do not require customers that customers have a domain registration with Amazon, use domain suffixes where Amazon is the registrant, or have other services from Amazon.
I wonder if they have plans for CloudFront too. That'd be a killer feature to be able to use HTTPS on cloudfront on a custom domain without it costing a fortune.
You already can do that for pretty cheap (if you use SNI), but only from the CLI and the command isn't exactly simple. [0] Having it integrated so you just click 'yes, SSL' and it handles cert generation and config would be great.
The problem is not the SSL certificate, the problem is the IP address. That will no longer be a problem as soon as IPv6 takes hold in a few years, I give it about 3. They currently have to deploy the SSL certificate to over 30 different IPs hence it costing the immense amount. The certificate can be had for $10.
I dunno where the line it, but Windows XP is in the ballpark of 2% of our traffic, depending on the site and how you measure it. The bummer is that HTTPS breaks kinda badly if you use an SNI cert and the OS/browser doesn't support it.
The latter sounds more likely to me. The sites I run get about 2.5% XP, but most of that population uses Chrome or Firefox. IE on XP accounts for only 0.3% overall.
At this point my experience is that most people still on XP are using IE - it mostly appears to be institutions that are still(!) using a primitive corporate build.
What's the benefit to serving your assets from a custom SSL-secured domain over https://whatever.cloudfront.net? The end-user doesn't really care what domain they're served from.
That would be nice, since managing SSL certs on ELB is currently the most painful way I've ever experienced. The documentation is vague, it's extremely finicky and doesn't give any useful feedback if you've done anything "wrong".
I knew that as well because I was equally surprised that the revocation lists are over HTTP and looked this up, only I did this a few years ago. Not very obscure in my opinion.
The fingerprints are included in the bugzilla ticket and the CRLs are signed with the certificates, so TLS doesn't technically add anything as long as you confirm the fingerprints (though it doesn't hurt anything either).
I don't think CRLs usually are, under current infrastructure anyway.
How can you verify the certificate of the server when it's signed by the certificate you want to fetch; or check that it hasn't been revoked when what you're connecting to is its own CRL/OCSP? What about the risk of infinite loops?
Cross-signatures, or multi-signatures, perhaps; or going opportunistic and simply not minding on that occasion?
Nope, for now they just use HTTP, and pin what they need to, to the fingerprint.
They should, however, specify an SHA-256 fingerprint. SHA-1 doesn't really cut it anymore. But that's what Mozilla currently require, so that's what Amazon provided. https://wiki.mozilla.org/CA:Information_checklist
No it's not. In order to establish a TLS connection, you'd have to do a revocation check. Can't perform that if you need a TLS connection to get the CRL.
As far as the certificate, I'm guessing there are many, many checks as to the authenticity of the key before it ships.
Plus, they'd have to use a cert from another CA, since theirs are not trusted yet. That's not elegant in a process that is used to start CAs.
And I can see exactly how they got to that mistake...
The writer was waffling between "We do not require customers to have a domain registration" and "We do not require that customers have a domain registration", and they forgot to remove the entirety of the old wording when replacing it with the new.
I've made this mistake myself several times, and it jumps out at me whenever I see it.
Since Amazon is an American company, would you trust their certificates? I mean are they going to give private keys to NSA or whoever is now spying in the US?
There isn't a single CA in existence that wouldn't be subject to nation-state pressure and/or infiltration. If NSA/GCHQ/FSB/etc. want to MITM you, they can probably MITM you.
I've always enjoyed James Mickens' perspective on this:
"In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@ virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. In summary, https:// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN’T REAL. When it rains, it pours."
While entertaining, this is a bit like saying that there are only two kinds of vendors: beach stalls that sell you icecream; and giant multinational conglomerates that have huge department stores. In reality, there's plenty of folks in-between.
If you're that concerned about centralised CAs, use self-signed certificates and distribute the keys to your users in-person. Once they get their browser to accept your certificate it will warn if it changes. Of course it doesn't scale very well, but for certain use-cases this "physical trust" system works.
There are, however, degrees of pressure resistance. Given AWS dropped WikiLeaks the moment a few politicians started getting upset, they seem unlikely to be very concerned with customer protection.
Because other countries don't have spy organizations either? I mean, who can you really trust these days. Even non American companies could be compelled to hand over their private keys IF the NSA were doing such a thing.
It'd be FANTASTIC if the NSA used Amazon's private keys. It'd leak tons of information and cause a huge backlash. Amazon's CA would instantly be revoked. It'd cause a ton of damage to them. That might spur tech companies to spend even more on buying politicians, which is probably a good thing (or a lesser evil).
The CA system is not great. But state actors using a CA is sorta far-down on the list of issues because it is so detectable and provable. CAs take a lot of work to get going and burning a CA isn't something anyone would do lightly. (Well except incompetent ones, like CNNIC.)
Neither do Verisign, Entrust, TrendMicro, IdenTrust, StartCom which are root certificate authorities your browser trusts right now. All of their sites are accessible over HTTP. It doesn't really say anything about whether you should trust their CA businesses.
The GP wasn't pointing out that Amazon is "accessible over HTTP". He was making the much stronger point that Amazon doesn't even offer HTTPS on most of its site.
I don't think any of the big (or small) corporations should be trusted, but in the case of Amazon, the question of trust in connection to data is much bigger than trusting them not to abuse powers from having SSL certs in the browser. They already run a huge part of the infrastructure of the Internet, and have the possibility of reading the private SSL keys of a number of services by virtue of hosting them.
The CA system is broken by design, but I don't think adding Amazon will make much of a difference either way.
The latency increase for HTTPS actually causes a measurable conversion difference in the e-commerce space. It sucks but it's true.
edit: Downvoters--have you ever done measurements? Why do you think Amazon redirects HTTPS to HTTP for product pages? It actually matters and at their scale it's real money.
Why would a redirect from https to http and then an http page load be faster than just returning the page over https? You're taking the SSL handshake latency hit either way.
You arguably shouldn't. We have way too many providers of certs as it is (including the Hong Kong post office, because reasons).
The answer isn't to attack Amazon, but to move to a model where basic certs (including wild card certs) are free or you don't get your root certificate in, only 3 companies get their cert in and none of the may be based anywhere but Germany or other countries that respect privacy.
But that is just the opinion of this random, angry, nerd.
That article is quite old (from Jan 2012). Amazon's independent publishing platform has extensive checks for plagiarism and content that is freely available on the internet. I know this system was there at least 6 months after that article.
Source: I used to work at Amazon in Independent Publishing.
(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)