Bug 266196 – Certificate error for playstation.com signed by DigiCert but not other DigiCert signed sites

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Alina Marquardt]

Created attachment 468966 [details]
certificate error when trying to visit playstation.com

Gnome Web 45.1 as well as Tangram 3.0 which uses WebkitGTK do not recognize the signing authority DigiCert on the current certificate of playstation.com, despite the same certificate authority being accepted on other certificates like for duckduckgo.com

In contrast, Firefox 120 on the same system, a recent Ungoogled Chromium and even Safari 15 on macOS 10.15 have no problem regarding playstation.com's certificate as valid.

Since I couldn't find out where WebkitGTK takes its certificates from and it's a breaking bug in Tangram for me I'm reporting this here. For now I'm assuming the certificates are built into the engine somehow or the error is coming from somewhere within the engine, since my installation is less than two months old, very recently updated and other certificates signed by DigiCert or other authorities pose no problem.

Steps to reproduce this:
- install NixOS 23.11 stable with `services.xserver.desktopManager.gnome` enabled, which installs among other packages
  - `gnome.gnome-shell` "Core user interface for the GNOME 3 desktop" 45.1
  - `epiphany` "WebKit based web browser for GNOME" 45.1
- run "Web"
- try visiting "playstation.com" and get a certificate warning
- verify with any other https site that has a cert signed by a diffferent certificate authority, that certificates in general are working
- verify with any https site that has a cert signed by DigiCert specifically (like "duckduckgo.com") that DigiCert as a certificate authority is valid

I hope to find a resolution to this problem, as I really want to use Web and Tangram with playstation.com

[Michael Catanzaro]

Hi, this is a server configuration error. playstation.com is sending its server certificate twice by mistake, and is not sending the issuer cert DigiCert Global G2 TLS RSA SHA256 2020 CA1, so there is no chain of trust and the rejection is correct. This is the sort of mistake that can only happen when you don't do any validity tests at all, because it will be caught by every test program imaginable. playstation.com should replace its extra playstation.com certificate with the missing DigiCert Global G2 TLS RSA SHA256 2020 CA1 intermediate certificate, and then it will work.

(In reply to Alina Marquardt from comment #0)
> In contrast, Firefox 120 on the same system, a recent Ungoogled Chromium and
> even Safari 15 on macOS 10.15 have no problem regarding playstation.com's
> certificate as valid.

Firefox goes out of its way to proactively download a big hardcoded list of intermediate certificates to reduce validation errors. It's even nondeterministic because it downloads a set number of certificates per day and whether the validation succeeds depends on whether or not you have the right certificate on any given day. That's nuts; we don't want that.

Chrome follows AuthorityInformationAccess to download the missing certificate automatically. This is more reasonable and I have a semi-working implementation of this from four years ago, but it's not good enough to land yet. I'll hopefully get back to it eventually. The downside of this is it allows the certificate authority to easily track you when visiting misconfigured websites, which is why Firefox doesn't do it, but our hand has been forced IMO. You can follow https://gitlab.gnome.org/GNOME/glib-networking/-/issues/96 if you want to see updates regarding this. Note the website should be fixed anyway because (a) obviously not everyone supports this, and (b) it's very slow.

I don't know what macOS does, but without any info I'd guess it uses AuthorityInformationAccess.

[Michael Catanzaro]

(In reply to Alina Marquardt from comment #0)
> Since I couldn't find out where WebkitGTK takes its certificates from and
> it's a breaking bug in Tangram for me I'm reporting this here. For now I'm
> assuming the certificates are built into the engine somehow or the error is
> coming from somewhere within the engine, since my installation is less than
> two months old, very recently updated and other certificates signed by
> DigiCert or other authorities pose no problem.

 * Certificate verification is performed by GnuTLS (hopefully) or OpenSSL (alternatively), via glib-networking, via libsoup
 * glib-networking will use your GnuTLS default trust store, which will hopefully be p11-kit if your distro is smart; generally non-Debian distros get this right. (I don't know what happens with OpenSSL, since OpenSSL does not have native support for p11-kit, but it will probably be whatever OpenSSL does by default.)