Meh, GoDaddy is relying on behaviour not specified/explicitly prohibited by RFC 5280. I'd prefer to ask them to fix it, rather than introducing an unspecified hack into Chrome, but then again, we're already getting that unspecified 'hack' from NSS, macOS, and CryptoAPI.

Namely, https://tools.ietf.org/html/rfc5280#section-4.2.2.1

   Where the information is available via HTTP or FTP, accessLocation
   MUST be a uniformResourceIdentifier and the URI MUST point to either
   a single DER encoded certificate as specified in [RFC2585] or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].

   Conforming applications that support HTTP or FTP for accessing
   certificates MUST be able to accept individual DER encoded
   certificates and SHOULD be able to accept "certs-only" CMS messages.

I'd like to reach out to them first.

Ok, would you like to do the reaching-out yourself or do you want me to? (I'm fine either way but would need an intro and/or contacts if you want me to do it.)

They are also not the only CA doing this; I'll attempt to put together a somewhat comprehensive list.

Just did :)

And yeah, that's something that I suppose we should have done sooner. It's not hard to get the AIA list from CT and check the compliance to these aspects. Happy to nag everyone, to see if there's some use case or interoperability concern we've missed.

If it's a large number, we might introduce a compat shim to allow it for a time, and I'll ratchet up pressure on CAs publicly and privately so that we could ultimately remove it.

Unfortunately, there's no good "AIA horked" reporting at the moment - although we could always suggest it to be added to certlint and/or crt.sh relatively easily (PRs welcome!). That might be a more effective long-term mitigation strategy.

This list is probably not comprehensive but looks like it accounts for most of the failures that we get in Chrome:

AlphaSSL: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
Starfield: http://certificates.starfieldtech.com/repository/sfig2.crt 
Cybertrust: http://sureseries-crl.cybertrust.ne.jp/SureServer/2021_ev/ctjevcag2_sha256.crt 

(can pull a more comprehensive list later this afternoon)

We updated the AlphaSSL CA certificate to be DER.

Thanks Doug! Let us know if there are any issues, and we can certainly discuss in the CA/Browser Forum if there's concrete data about clients that expect PEM rather than DER - and we can look to express that both in the BRs and our client code, much like the discussions around nameConstraints :)

DigiCert has confirmed they've worked with Cybertrust Japan to correct http://sureseries-crl.cybertrust.ne.jp/SureServer/2021_ev/ctjevcag2_sha256.crt

GoDaddy has indicated they expect to make the change in 3 weeks.