Unfortunately, StartSSL / Startcom certs are likely to not be trusted in the not-too-distant future, thanks to a nasty flaw in their DC validation process:
In any event, I’m not willing to go down that road at the moment.
In addition to iTunes having a problem, after enabling SSL on my RSS feeds, I received a bunch of reports from listeners that reported they were unable to download my podcasts. It looks like several apps on Android (DoubleTwist, BeyondPod) as well as Microsoft’s Podcast app on Windows Phone had issues. As soon as I disabled SSL, they were able to automatically download the episodes. This is going to be a big issue for a lot of podcasters, but hopefully this gets ironed out over the coming months with platforms and apps getting updated.
Besides copy&paste media, I’ve not seen anyone actually blaming StartSSL CA after this report or even indicating the respective Root CA was about to be banned.
Note that this was, in the end, a false claim. See StartCom’s response.
Also the next day StartCom started using Certificate Transparency on all their certs:
https://www.startssl.com/NewsDetails?date=20160323
As this is apparently better than Google, and I suspect other CAs haven’t even done this yet, I doubt they will be ‘banned’.
BTW I’m no apologist for StartSSL - there was a real issue with them charging for Heartbleed re-issuing of certs which I thought was really crappy (but that issue is over now, as it’s well over a year so all certs will have expired). Hence why I wanted to switch ALL my sites to LE .And to some extent you get what you pay for…but it’s not fair to claim they are somehow ‘insecure’.
It doesn’t appear to just be iTunes, but now I’m getting reports that iHeart Radio stopped processing feeds because of a move to SSL using Let’s Encrypt. This is really bizarre and I have no idea why they don’t like the certificate.
Possibly they don’t have trust for the root. The way it was mentioned earlier, Apple is using Java on their backend, which doesn’t include the DST root. It may be similar for iHeartMedia.
What I did, was simply create a sub-domain that was not on HTTPS feed.mydomain.com, and used PHP to copy my feed into the index of the new url. So instead of www.mydomain.com/feed/podcast, my new feed is just feed.mydomain.com.
Supper sketchy, but it works, and ITunes accepted it.
Here is my php code
<?php
$content = file_get_contents('https://www.learnjazzstandards.com/feed/podcast/');
$content = new SimpleXMLElement($content);
Header('Content-type: text/xml');
print($content->asXML());
?>
3 Likes
Received an email from iTunes Podcast Connect today titled "Podcast News & Announcements." They now seem to be pushing SSL, which is a first. Previously, they only hinted at requiring it in the future at an unknown date. Doesn't look like they fixed the Java backend in iTunes, because they provided a list of recommended certificate authorities and not Let's Encrypt.
iTunes desktop and the Podcasts app for iOS and tvOS both support HTTPS protocol for metadata, cover art, and episode files. We require an SSL certificate from one of the following providers:
https://www.godaddy.com/ssl/ssl-certificates.aspx
http://www.symantec.com/ssl-certificates
Compare SSL Certificates Prices & Features | Thawte®
SSL / TLS CERTIFICATES
http://www.entrust.net
TLS SSL Certificates | GeoTrust
http://www.affirmtrust.com
https://www.comodo.com/
and also not identrust, which essentially backs LE.
And oddly not mentioning StartSSL - which does work…
Although apparently that support might not be always there either, I forget what reason, something to do with the type of certificate? :-/
I haven’t looked at this issue since June and it’s still a problem. Just today I noticed iTunes podcast connect throwing the following message:
“Can’t read your feed. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target”
1 Like
Thanks for the update, @zerodistraction – I suspected it was still true, but I appreciate your confirming this.
Well @ecdsa-chacha20 – I may not have chosen the most reliable source to link to at the time, but within the security community, StartCom has known to be problematic for quite some time.
Mozilla certainly seems to think there’s something to the problem:
https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
Oh, come on @TheDavidJohnson, there has been quite some other news around StartCom and WoSign since April. Where’ve you been all the time?
1 Like
I’ve been tracking it all along, but I’d forgotten we discussed it in this thread. Since I was in here today for another reason, I thought we better have an update of some kind about StartCom for the sake of anyone who stumbles across this thread and isn’t aware…
Aware of that, although my StartSSL sites seem to be still OK in Firefox and my podcasts are also still in iTunes.
Would love to know of another free cert that works with iTunes? I don’t think there is one. Yes I know there are paid alternatives, but given I have no money coming in atm, all unessential costs like SSL certs are banned. Saying it’s ‘only $5’ when I don’t have those $5 doesn’t really help.
Security community can throw their toys out of the pram, but if they block StartSSL then I’ll just have to live with that browser not working with my sites. shrug. Their choice. I suspect a lot of other Startcom users will be similar…
"That browser" in this case being Chrome, Firefox and I think also Safari. So, basically everything people actually use besides Internet Explorer, for now (Microsoft are sometimes slow to decide policy on these things, but a Patch Tuesday can change the installed CA certificates on every Windows PC overnight...). The announced policy change is to reject new certificates, to avoid disruption for people like you whose certificates appear to have been issued in good faith prior to the announcement. This may have to change if there is further misbehaviour involving fake timestamps.
I presume that eventually Apple will catch up to the modern era and the Let's Encrypt certificates will work with iTunes, but that's really up to Apple and/or their customers.
And if enough sites get blocked then it’ll backfire. Safari and Apple don’t do the same program as Mozilla, they’re separate. Firefox - given today’s news about the 0-day exploit on Windows that wouldn’t be much of a loss, I think FF is on the way out tbh - and maybe Chrome.
It would be annoying, but since I don’t have the $$$s to change it, and I obviously can’t change how these spats play out, not much I can do about it.
Best I could do is go back to HTTP. Big woop for security, there. slow clap. I think SOME encryption is better than none, but those stressing about this seem to want to force people to pay for certs that offer no extra security, really. I wonder if they work for the paid CAs? I betcha they do.
And Apple won’t change it, they’re aware but they obviously don’t want to shut off older browsers or are using an older version of Java for compatibility. LE isn’t compatible with the version of Java/JDK they’re using to develop their server software…and I suspect that’s unlikely to change.
Existing certificates issued before a certain date will continue to work - that's the solution that Apple, Mozilla and Google have proposed and/or shipped (all of them - no reason to single out Mozilla here, they're just the only ones operating an open/transparent root program.) Not sure what you're referring to about the separate program?
This doesn't make any sense. First of all, some encryption at the cost of risking that these obviously broken CAs continue to mis-issue certificates is definitely not better than none. Browsers might as well accept self-signed certificates if that's how they run their root programs.
Second, both Google and Mozilla are Platinum sponsors of Let's Encrypt, and they've made this decision. Are you saying they've been manipulated by other CAs, or that they themselves (somehow?) work for them, or get paid by them? Also, if that strategy would work, why aren't CAs constantly trying to get rid of competition that way?
It's important to see past the inconvenience that a particular change is causing and consider all the factors. Browser vendors have already gone out of their way to make the impact for existing users of these CAs as small as possible, some of them have helped establish Let's Encrypt, etc. They can't take care of everything.
This is just a backend issue - there would be no impact on browser compatibility. They don't even have to upgrade Java, just modify their trust store.
2 Likes