Bringing up LE to match StartSSL's offerings

as you said the ultimate control is still at the top so they could just remove the delegation, get the cert and restore it, just saying

try fhat with a ton of names and tell me it's still practical.

@tialaramex while I dont care much of the TLDs, I also think dane is good especially because the top root ceremony is so open and for the domain registries I dont know but at least from the tree structure I dont have to worry when for example and Indian TLD gets problems with DNSSec coz the TLDs cant affect each other.

@pfg handing it into the US for many TLDs isnt the greatest Idea but it's imo better than essentially handing it to some-hundred different CAs, subCAs and whatever at the same time.

If the CAs would at least be limited in what in what they can issue it would help, but no, many of them have no limitations whatsoever, and that CAs can go wrong is something we can see with symantec all the time, but also comodo and most recently startcom and wosign.

I honestly dont even want to know if the government of some weird country like china or whatever forces the CA to make certs, and with a gag order they couldnt even talk to anyone to revoke the trust or whatever. (well at least until all browsers force CT)

10 names, 10000 names, what's that to a script...

if you can script your DNS down,

If your environment is complex enough to have these sorts of requirements, it ought to be powerful enough to accomodate them.

If you can't programatically make changes to your DNS records, the dns-01 challenge probably isn't for you anyway.

but then again if you could just enter you account key and have a walk-up for the DNS challenge this would make scripting a lot easier since your host just needs to do the direct stuff with LE no additional “fun” needed

I think it’s one of those things that sound great in theory, but wouldn’t lead to any improvements in practice. 69 domains in the Alexa top 100 end in .com, .net or .org and are therefore essentially under U.S. control. It would be just about impossible to get rid of those TLDs in the event that those registries become complicit in MitM attacks. And while the DNSSEC root signing ceremonies might be fully transparent (and hey, they even joined the RSA-2048 club recently! :laughing:), I’m not so sure about the practice of registries - do they have the equivalent of Baseline Requirements, and who’s going to enforce them? (Honest question, I’m not familiar with that aspect of DNSSEC.)

DANE doesn’t hold any advantage over the Web PKI with full transparency and HPKP, in my opinion - and if you’re capable of running your own DNSSEC infrastructure, you’re probably qualified to use HPKP as well. I think it’s important that we not only look at “Web PKI vs DANE” but rather Web PKI + all mechanisms browsers give site operators and users to detect mis-issuance and prevent attacks from mis-issued certificates. After all, DNSSEC/DANE is an entirely new thing that site owners have to deploy as well, so the “but no one is using that!” argument doesn’t apply (since apparently no one is using DANE either).

well the gTLDs do have their problems (well as it seems at least the TLD I use is in ireland, nice.), I can see that one but CAs still have the one great problem that they are not limited in ANY way, and while CT is not bad, it wont do enough if not all browsers require it for any of the public CAs.
accordng to this nice little file:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReportCSVFormat
there are 177 CAs in FF’s trust store and many of the are roots with quite a few intermediates but if we just assume 2 per CA we would have 531 certs (the roots and the intermediates) that are practically allowed to sign anything for the internet.

This. The fantasy that its about trust is ....... wishful thinking. No matter what you want issued, one of those ~500 providers WILL give you what you want if you have a credit card and do instant payment.

The reality is that you just hope the CAs as a whole don't do anything malicious (but would you know if they did?) and that anything is really better than plain text. It won't keep the spooks out, but it stops Joe Blow with wireshark and lots of free time - or your ISP from gathering info. Beyond that, the idea of trust in SSL is snake oil in IT form.

To add to that thought, would you trust your bank to use Lets Encrypt?

well the approximated 500 dont all belong to different entities (I just assumed each one has 2 intermediates having one main and one backup) but still with 177 CAs you probably will still find something.

Fun fact: Three of Verizon’s old roots have over 200 sub CAs.

https://groups.google.com/d/msg/mozilla.dev.security.policy/tHUcqnWPt3o/U2U__7-UBQAJ

wait a sec

After watching the issuance of wildcard EV certs

wait what? just how? dont browsers realize that wildcard EVs shouldnt exist?

but over 200 intermediates under one company's root certs? how do they even control that each of those does what it should? and let me guess most of them didnt even have constraints, or did they?

Well, as Verizon the answer is “not very well”. DigiCert felt that purchasing the whole mess and bringing it under their control would work out better for everyone than waiting for that particular can of worms to be opened by the trust store operators as you can see in that thread.

The situation we inherit is that the Web PKI used to be a real Wild West, and so things dating back five, ten, fifteen years look outrageous today. Only literally last month were public CAs even required to revoke any remaining non-Internet TLS certificates, that’s right, a month or so ago it was still OK to present bona fide Web PKI certificates which said your server was named “exchange2013” or “test02” or had the IP address 10.20.30.40 even though there’s no possible way those could have been properly validated when they were issued!

In that atmosphere you can imagine that a company buying a service from Verizon in 2010 might have never understood that they were participating in this big serious thing called the Web PKI and they were required to be audited to meet standards set by browser vendors, and so on. They put a machine in a rack somewhere, a few people knew the password, and they get the power to issue certificates without all that nonsense with filling out forms, convenient. And a nice money earner for Verizon. For a while.

Damn, if StartSSL go down, I’ll have to abandon SSL for my podcast sites completely. Can’t afford new certs atm, and can’t use LE because, as the thread I started years back here will tell you, iTunes/Apple’s Podcast Connect doesn’t support LE certs at all - I forget the details but it’s something to do with Java I think, and/or cert support of the old version that Apple uses. (Don’t shout at me if that’s not the case, go read the thread here).

All I know is I used the LE certs and Podcast Connect wouldn’t accept them and pulled my podcast off the store. And StartSSL worked, even though I know all of the bugbears that the infosec community hate about them, and I too was affected by Heartbleed and the $25 revocation charge was a real pisstake - but the (probably justified) haters seem to ignore one thing: they were/are free, and widely supported, and fairly easy to get, strange browser certs notwithstanding.

As far as I know there isn’t an alternative like that, free certs that are widely compatible. LE SHOULD be, but it isn’t. (yet?). I used LE for all my other sites, I’d love to use it for my two podcast sites too. But can’t.

Yes Apple are aware, no it probably won’t change, yes StartSSL worked and was fine because it was cross-signed with one of the supported CAs. So I think the OP is correct, if LE wants to go ‘large’ and bigger, it needs to work with companies like Apple, or get some cross-signing support that increases such compatibility (apologies if it has already, but I’m monitoring that iTunes thread and it still seems an issue). I’m not even bothered by the 90 day now the script seems to be working well (it had so much bugs in the beginning!) but if you want this to go out of it’s bunker and into the wider world, Apple and others HAVE to be on board with support. Until then, non-geeky people won’t care about all the reasons/excuses, the people like me who can’t really tell their elliptical crypto from their elbow - it’ll be ‘it doesn’t work’.

Which given LE’s aim is to demystify and make it easy for ‘normal’ (i.e. non-techy) people to do, is a bit of an own goal?

1 Like

You mean in making it easy for newbies, but not flexible enough for advanced users who have more than just a basic 'I run apache!' setup? If so, I agree :\

Well it depends, if you want SSL to be on every site - which is the goal of this project - then you have to engage with those users, and let the techy ones mostly sort out their issues themselves, as they tend to do. They have the ability. Others don’t - that’s why SSL hasn’t been adopted everywhere because it’s an arse to install, and costs.

If you want it as a pet geeky project that’s ‘My Precious’ and no-one else can play in your sandpit? Then go ahead as you are. There are loads of projects that are headachingly hard to install, it’s a busy sector :stuck_out_tongue: Making it easy…that’s hard. Getting geek cred? Quite easy.

I’ve had to do a LOT of work to make it work, I don’t run a basic Apache setup either. It’s not feasible for LE to hold the hands of everyone. But they CAN sort out the CA issues with compatibility, cross-signing etc. Sadly iTunes/Podcast Connect doesn’t support IdenTrust either!

1 Like

The issue with Apple is that they use Java and the built-in trust store doesn’t include the IdenTrust CA certificate. I understand that there is movement to include either the ISRG or DST (IdenTrust) roots, but Apple would need to update their backend Java tech. Alternately, they could make a custom trust store, but I don’t see that happening as their back-end tech seems awfully lacking and shoddy. User-facing stuff that Apple has created works fine with the DST root.

StartSSL has the advantage of enough history that they were included for compatibility with the Java trust store. I don’t think they would have been able to be in otherwise.

How many certificates do you need? You can find commercial single-domain ones as low as $7-9 per year. Also, you could move your podcast files to a single domain but keep the other resources on their own sites.

i have zero dollars to spare, already scaling down servers to keep them up, and planning to combine servers to save money. Close to shutting the whole lot down, because I have no money coming in. Zero. Nada. Nothing. So more for SSL certs, not going to happen when I’m standing in the supermarket worrying over what food I can afford…I only need 2, but it’s more money that takes my overdraft further into the red. Not good.

“Also, you could move your podcast files to a single domain” - I’ve been podcasting since 2004, I have hundreds of blog posts with the links, and legacy links. I did all this when I updated to HTTPS, it took me days and days to update them all…yes auto-updating doesn’t work that well. So that’s a no go, although I guess I do have the time, I’d rather spend it elsewhere atm.

Simplest option? Switch off SSL and update the link in iTunes to HTTP. That won’t take days of work. Then again I need to update all the links that are HTTPS. Grr. Luckily the RSS have to be HTTP, and I used // quite a lot instead of HTTP/HTTPS. So it might be.

I think I’d have to accept that FF users will be locked out, leave it and see what happens with the Mozilla/Wosign bunfight.

Well, given the speed of updates Apple makes on their back end systems, you’ll probably be fine with StartSSL certs long after the browsers and client-side stuff stops trusting them.

So, essentially what I’m getting from skimming this thread is “we’ll continue to ‘consider’ wildcard certificates which will most likely take years to go anywhere, forcing you to go back to the ancient model of ponying up $50+ per domain if this happens to be something you need come January” and “90 days is plenty for everyone and fits every use-case that exists which we care about, go pay for security if you want something different”. That about right?

For what it’s worth, I understand the benefits of 90-day certificates, and I’ll continue to use them if/when longer lifetimes become available. At the same time, I understand that it’s not a one-size-fits-all solution.