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
https://www.thawte.com/ssl/
https://www.globalsign.com/en/ssl/
http://www.entrust.net
https://www.geotrust.com/ssl/
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
Apple can fix this as @pfg said. It’s just a matter of them choosing to do so. Why don’t we all open tickets with them specifically requesting that they add LE support?
I found this email for opening tickets for podcast-related stuff: PodcastSupport@apple.com. If we all message them, creating a bunch of tickets, hopefully it’ll put some pressure on to update their trust store and let us use LE for podcasts.
EDIT: if you want to make it really easy, here’s what I wrote so you can copy/paste:
Please update your SSL trust store to include Let’s Encrypt SSL certificates! iOS, OSX, and macOS all trust Let’s Encrypt sites, so please add it to iTunes as well. It’s extremely frustrating that we can’t submit podcast feeds that are SSL encrypted using Let’s Encrypt. Let’s Encrypt is backed by Google, Mozilla, Automattic, and others. Please fix this asap.
2 Likes
Already done that - 26th Feb 2016:
"Hello Tim,
Regarding LE certificates, I thank you for the feedback, and will forward your comments to the appropriate team.
Please let us know if we can assist with anything further.
For reference, your case number is xxxxxxxxx.
Anthony
Apple Inc."
1 Like
Maybe not Google and Mozilla, but it’s not just them causing a fuss about this?
The whole thing just leaves a nasty taste in my mouth…I understand the problems, but as you can see from this thread there always has been a residual hatred of StartSSL. And it’s not great, but as this whole thread proves, LE is far from a replacement.
‘Just’ modify the trust store? You make it sound easy, but Apple is a corporation.
Also nice that you’re comfortable enough or not affected enough (or not caring enough) that it’s an ‘inconvenience’. Us in the real world outside of encryption geekery - which is what LE has to appeal to, and was supposed to open the door to - have a different response to having to probably buy SSL certificates that they cannot afford?
I’m guessing you’re in the ‘just $5’ set (which it isn’t because I have multiple podcasts) that I’ve encountered before? Well unless I start making advertising revenue, dunno where that extra money is coming from…
(I could add the case number if you want, I couldn’t think of how someone could abuse it but just in case I didn’t add it, but if someone is approaching them, it’s well worth pointing out it was raised nearly a year ago)
You’re right - people who’ve been keeping track of their issues for quite some time have been outspoken about this, even before the final events that lead to their removal. The vast majority of them don’t work for CAs. StartCom has had incidents before, and they didn’t make any friends when they refused to revoke certificates that were potentially compromised by Heartbleed either.
I don’t know, I’m more concerned about the fact that a corporation the size of Apple doesn’t have procedures that would allow them to update their trust store in the event that a CA is compromised (which has probably happened a couple of times since their last Java update 
).
Sadly, I’m quite familiar with this kind of corporate inertia, but I’d rather not base root program policies around them.
Let’s not lose track of the big picture here. This is one use-case, one vendor, one particular application. Let’s Encrypt works (and is free) for a myriad of others. It’s not always possible to make every single person happy, and in this case, it’s outside of the control of Let’s Encrypt. I understand your frustration, but it’s misdirected and your suggestion to keep trusting CAs that would work for your use-case even though they’re a risk to the ecosystem is a bit short-sighted.