I just moved those files back to Netlify, only to discover that the issue is not yet fully resolved. Older Electron versions are happy to download files from our Netlify site at rev-robotics-software-metadata.netlify.app, but still get certificate errors when downloading files through our custom subdomain, software-metadata.revrobotics.com.
For now I can direct the traffic to the netlify.app location, but it would be nice to have the certificate issue resolved at our custom subdomain too.
As a side note, when I click the “Renew Certificate” button and accept the confirmation, it says “sending request”, and then nothing happens. So far, the certificate update date remains at October 27.
The link you shared mentions that this is Lets Encrypt that has changed and not Netlify. Lets Encrypt not doesn’t support providing certificates that would be accepted by older clients. There is nothing Netlify can do to fix (change) this.
The netlify.app subdomain works because Netlify doesn’t use a Lets Encrypt certificate for that.
The “solution” in your case is to purchase a custom SSL certificate from elsewhere and install it in your Netlify site settings.
It’s possible to work around the issue on the server side without switching away from Let’s Encrypt by disabling the certificate chain that contains the expired DST Root CA X3 certificate. See this post by Let’s Encrypt, that explains that the default chain includes the expired certificate, but that many ACME clients allow you to specify an alternate chain that does not include the DST Root CA X3 cert. For certbot, you select the alternate chain using --preferred-chain "ISRG Root X1".
The alternate chain doesn’t support Android devices older than 7.1.1, but that’s not a problem for my use case.
I’m not sure how my last comment got marked as the solution. @hrishikesh Is this something that Netlify can configure for us? There’s an additional issue caused by the current situation that’s much harder to work around.
It looks like the one you mention is supposed to be supported by new devices only (that’s what’s happening).
Yes, but won’t that be a problem for others? I think Android is working because of something Lets Encrypt has done as mentioned here:
I would like to reiterate that the easier solution would be to get a different SSL certificate, because even if there’s something that Netlify can do, it might not happen immediately.
A lot of certificate viewers seem to stop displaying anything past a valid root certificate (or maybe they’re just ignoring the other root because it’s expired). If you go to this link, expand the Certification Paths section, you’ll see an untrusted Path #2, which is what I’d like to get rid of.
won’t that be a problem for others?
My ideal solution would be to allow individual sites to opt-in to the shorter certificate chain.
It’s not urgent to have the subdomain working with Electron just yet. If it becomes that way before Netlify provides an opt-in option, I’ll probably set something up with a serverless function, the Netlify API, and the desired Let’s Encrypt settings. Manually messing with certs is not a chore I want to have to remember.
Sorry for the delay here, we have been a bit underwater this week. I wanted to reach back out and see if you are still encountering obstacles. Please let us know!
At this point, you should consider this thread as a feature request for being able to opt-in to the shortened certificate chain, either via the web interface or via a support request. That feature will be valuable to me until September 2024, which is when the DST Root CA X3 certificate will expire, and Let’s Encrypt will presumably remove it from the chain for all users.
