P.S. mede gezien hoe T-Mobile met hun klanten omgaat heb ik geen zin om uit te zoeken hoe ik hen hierop kan wijzen (met een grote kans dat ik mijn tijd verspil - "in Chrome werkt onze site prima").

Wat is nu de link met dit certificaat en het T-Mobile/CBS bericht?

Of zag je daar een post van een tweakers-bezoeker?

Of wilde je zeggen: "Een certificaat van QuoVadis is ingetrokken"?

Hier is ie gesigned met een ander certificaat dan bij jou. Dus ofwel ze hebben dit al opgelost, ofwel er zijn wellicht meerdere alternatieve servers ofzo.

Als ik naar de betreffende site ga, zie ik een certificaat met SHA256 hash F6:7C:23:EF:7B:F7:41:28:09:DB:6B:1D:D3:D4:4A:08:D3:75:4D:99:CA:BA:6A:13:F7:A0:5C:72:49:08:9C:89 voor "QuoVadis Global SSL ICA G2". Dat is dus een ander certificaat. De betreffende site loopt via cloudfront. Ik denk dat daar iets niet in de haak is op een of meer servers (wat met goed configuratie management natuurlijk niet mag gebeuren). Met mijn browser (up-to-date Firefox) is niets mis.

Volgens https://www.ssllabs.com/ssltest/analyze.html?d=community.t-mobile.nl gaat het om (alle?) 12 servers die een ingetrokken certificaat versturen.

Ik heb verder gepuzzeld: het lijkt er sterk op dat, als Firefox een geldig intermediate certificaat in z'n cache heeft, het meegezonden (ingetrokken) certificaat wordt genegeerd.

Als test heb ik uit https://knowledge.digicert.com/quovadis/ssl-certificates/Intermediate-CA-Revocations-January-2021.html de nieuwe "QuoVadis Global SSL ICA G2" gedownload (directe link: http://trust.quovadisglobal.com/qvsslg2.crt) gedownload (SHA256: f67c23ef7bf7412809db6b1dd3d44a08d3754d99caba6a13f7a05c7249089c89). Deze heb ik geïmporteerd in Android. In Firefox Nightly (waarin https://community.t-mobile.nl/ ook een foutmelding gaf) heb ik vervolgens, in about:config, "security.enterprise_roots.enabled" op True gezet. Daarna opende https://community.t-mobile.nl/ inderdaad zonder foutmeldingen (alleen in FF Nightly, de "gewone" Firefox geeft nog steeds een foutmelding).

Lessons learned:
1) Browsers (alle?) lijken meegestuurde revoked certs te negeren als een niet-revoked vervanger in hun cache zit;
2) Check je https servers regelmatig met een "clean" browser (account) om dit soort issues op te merken;
3) "QuoVadis Global SSL ICA G2" is opnieuw uitgegeven met ongewijzigde public key (wat was er mis met het oude cert?).

@Roger63: zou je, ter bevestiging, dat nieuwe intermediate certificaat uit de browser-cache kunnen halen (voor zover ik weet kan dit niet met Firefox mobile), de browser stoppen en starten, en kijken of je dan nog steeds zonder foutmelding https://community.t-mobile.nl/ kunt openen?

Toch een dergelijke opmerking: ik probeerde het net in Firefox en kreeg geen foutmelding.

Het kan zinvol zijn om je browsercache te schonen of een reload met de SHIFT-toets ingedrukt te doen. Mij staat bij dat ik in het verleden heb meegemaakt dat Firefox responses waar het foutmeldingen aan kopelde in de cache opsloeg en bleef laten zien nadat de fout feitelijk al niet meer van toepassing was. Het kan het proberen waard zijn.

Zojuist een schone VM aangemaakt, firefox-esr gestart en naar de URL gegaan. Geen probleem gezien en gewoon een geldig certificaat.

Ik heb in Firefox 86.0 bij Clear Recent History alles weggegooid (alle vinkjes aan en Everything geselecteerd als time range; ruimt lekker op) en ben daarna naar de site gegaan: geen foutmelding. In de certificate viewer (Certainly Something extensie) zie ik het nieuwe intermediate certificaat en niet het gerevokete exemplaar dat in Firefox zelf zit.

Ik krijg het volgende resultaat
En weer zit Amazon er vuistdiep in kennelijk:
https://sitereport.netcraft.com/?url=https%3A%2F%2Fcommunity.t-mobile.nl%2F
Geldigheidsduur: From Feb 25 2020 to Feb 25 2022 (24 months)
Certificaatherroepingslijst van: http://crl.quovadisglobal.com/qvsslg2.crl
Zie certificaat tranperency (3 partijen) DigiCert, Sectigo Mammoth en het niet te vermijden Google Rocketeer.

Tracking gebeurt via ompany Primary Category Tracker
Amazon CDN Cloudfront
Google Analytics Googletagmanager

luntrus

In Safari is die site gewoon te openen (alles up-to-date).

Opvallend genoeg geeft ook https://crt.sh/?caid=1368 alleen een revoked aan op heel specifiek e-mail.

Zojuist nog even Firefox 86.0 (Linux) getest maar ook niet kan ik het niet reproduceren.

Allen dank voor de reacties! Na verder onderzoek kom ik tot de volgende conclusies:
1) https://community.t-mobile.nl/ stuurt wel degelijk een revoked intermediate certificate mee;

2) Er zijn veel meer servers dan genoemd in https://www.ssllabs.com/ssltest/analyze.html?d=community.t-mobile.nl (ik kon sowieso 12 unieke IPv4 en 24 unieke IPv6 adressen vinden, indien gewenst post ik de adressen). Ik heb ze niet allemaal getest, maar vermoed dat ze allemaal dat revoked intermediate certificate meesturen;

3) Het feit dat tweaker "dutchminator" in https://tweakers.net/nieuws/179090/t-mobile-deelde-herleidbare-locatiegegevens-met-cbs-voor-bouwen-van-algoritme.html?showReaction=15760826#r_15760826 en ssllabs (naast mij) ook certificate errors zien, betekent dat het niet alleen een probleem bij mij is;

4) Kennelijk checkt Firefox desktop intermediate certs niet op revocation, Firefox voor Android doet dat kennelijk wel (daarom kreeg en krijg ik een foutmelding op mijn smartphone). Mijn excuses voor het feit dat ik ervan uitging dat ook Firefox desktop dat zou doen (ik vind het teleurstellend dat dit niet zo is, en ook kon ik er geen about:config instelling voor vinden). Ook had ik beter meteen kunnen melden dat ik Firefox op Android gebruikte, maar dit verschil verwachtte ik niet;

5) Als in Firefox voor Android (in elk geval de nightly versie) het nieuwe intermediate certificaat "voorbijkomt" zal ook deze versie van Firefox dat certificaat cachen, waarna een door de server meegestuurde (ingetrokken) versie van het certificaat wordt genegeerd en er geen foutmelding meer optreedt;

6) Op de volgende pagina's kun je respectievelijk het ingetrokken en het nieuwe intermediate certificaat bekijken:
https://de.ssl-tools.net/certificates/6036330e1643a0cee19c8af780e0f3e8f59ca1a3.txt
https://de.ssl-tools.net/certificates/15342bbb20b25efb48fda23b7b1fe5550b9560da.txt
Naast het serienummer zijn dit de belangrijkste verschillen:
Vermoedelijk is het certificaat opnieuw uitgegeven omdat de "Extended Key Usage" gegevens ontbraken (de public key is hetzelfde gebleven, anders had het servercertificaat ook vervangen moeten worden). Er lijkt dus geen sprake van een beveiligingsprobleem met het oude certificaat.

Onder Windows heb ik Firefox ESR 78.8.0esr (64-bit) gestart met de commandline parameter -P en een nieuw profiel aangemaakt. Daarna heb ik https://community.t-mobile.nl/ geopend, dit gaf inderdaad geen foutmelding. Echter, het intermediate certificaat is wel degelijk het ingetrokken certificaat:

  Serial Number: 48:98:2D:E2:A9:2C:B3:39:E1:C8:F9:33:35:82:75:D3:E4:F8:82:55
  SHA256: A4:87:9E:C0:F3:6C:F8:4B:6F:2E:D8:7A:E5:7E:E3:B9:4A:07:85:C6:86:22:38:CD:45:48:10:84:D1:52:EB:18

Als ik vanuit mijn gebruikelijke Firefox profiel https://community.t-mobile.nl/ open, zie ik voor het intermediate certificaat:

  Serial Number: 1A:6E:E8:93:C3:74:97:38:E1:2A:CC:C7:7A:8C:0A:CB:16:7E:AF:14
  SHA-256: F6:7C:23:EF:7B:F7:41:28:09:DB:6B:1D:D3:D4:4A:08:D3:75:4D:99:CA:BA:6A:13:F7:A0:5C:72:49:08:9C:89

maar dat is niet het certificaat dat door de server wordt meegestuurd (dat kan ik zien in Wireshark als ik TLS v1.3 uitzet in Firefox), dus kennelijk is het nieuwe certificaat door een andere site aan de certificate store in mijn gangbare profiel van Firefox toegevoegd (in de file "cert9.db" in dat profiel).

Dank ook voor jouw hulp! Helaas verwijder je geen intermediate certificaten met het leeghalen van de browser cache. Sterker, het lukt mij niet eens om in mijn profiel "QuoVadis Global SSL ICA G2" (een "Software Security Device") te verwijderen (als ik een nieuw profiel in Firefox aanmaak, bestaat dat niet). D.w.z. dat verwijderen lijkt te lukken, maar als ik opnieuw de certificate manager in Firefox open, is dat certificaat weer terug.

Conclusie: https://community.t-mobile.nl/ stuurt een revoked intermediate certificaat mee, maar Firefox desktop checkt niet op revocation daarvan (Firefox voor Android wel). En als je toevallig een latere versie van een intermediate certificaat in de certificate store hebt, gebruikt Firefox dat en negeert kennelijk het meegestuurde intermediate certificaat.

Als ik met Safari 13.1 kijk, zie ik ook dit intermediate certificaat. Safari slaat zelf geen certificaten op, maar doet het certificaatbeheer via het os. (Net als chrome op de mac)

Dan was de nieuwe versie van dit certificaat ook bij jou kennelijk al gecached (in een "dynamisch" deel van de certificate store) in het OS.

Vermoedelijk bedoel je browser (i.p.v. e-mail), maar dank voor deze link! Volgens https://crt.sh/?caid=1368 zou alleen Firefox dit ingetrokken certificaat blokkeren op basis van "OneCRL" - maar in elk geval Firefox ESR (desktop) doet dat niet (bij mij en bij Anoniem van gisteren 15:58).

Opmerkelijk: in https://crt.sh/?id=2488230 is te zien dat hetzelfde certificaat ook door Google's "CRLSet/Blocklist" wordt geblokkeerd - maar welke browsers die lijst gebruiken, weet ik niet.

Ik heb me wat verder ingelezen: Mozilla heeft OneCRL in 2015 geïntroduceerd om revoked intermediate certificaten mee te blokkeren. In https://crt.sh/mozilla-onecrl zie je alle geblokkeerde certificaten in een recente versie van het OneCRL bestand.

Redelijk nieuw is CRLite waarmee sterk gecomprimeerde blocklists zijn te maken (zie https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland17.pdf en https://blog.mozilla.org/security/2020/12/01/crlite-part-4-infrastructure-design/).

Ik heb geen idee of CRLite op dit moment al wordt gebruikt in Firefox ESR, noch of deze OneCRL aanvult (tevens gebruikt wordt) of vervangt. Weet iemand meer hierover?

Ik heb verder onderzoek gedaan. Firefox toon geen certificaatfoutmelding als je https://community.t-mobile.nl/ opent:
1) Als de nieuwe versie van het ingetrokken intermediate certificaat al in de certificate store (cache) zit. Zo niet:
2) Als het OneCRL bestand nog niet is gedownload; het downloaden daarvan gebeurt pas enkele minuten na het aanmaken van een Firefox profiel (daarom zie je geen foutmelding als je Firefox in een VM installeert en/of een nieuw profiel aanmaakt en https://community.t-mobile.nl/ meteen opent).

Punt 2 geldt in elk geval voor Firefox ESR (desktop) als Firefox Nightly op Android.

Of dat "OneCRL" bestand is al gedownload, kun je zien in about:config door te filteren op "onecrl": zolang de variabele "services.settings.security.onecrl.checked" de waarde 0 heeft, is dat bestand nog niet gedownload. Onder Windows is er dan een bestand (momenteel minstens 731kB):
  C:\Users\<account>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile-ID>\security_state\data.safe.bin

In mijn gebruikelijke profiel was dat bestand ruim 4MB groot en bevatte kennelijk ook een volledige kopie van het nieuwe intermediate certificaat, want ook na het verwijderen van "cert9.db" [*] bleef Firefox dat gebruiken en gaf geen foutmelding als ik https://community.t-mobile.nl/ opende. Na het verwijderen van zowel "cert9.db" als "security_state\data.safe.bin" lukte het mij niet om binnen enkele minuten Firefox te dwingen om een nieuwe versie van OneCRL ("data.safe.bin") te downloaden, ook niet door het op 0 zetten van timers in "about:config" gefilterd op "crl". Wat wel werkte is het downloaden van dat "security_state\data.safe.bin" bestand in een nieuw profiel, en dat kopiëren naar bovengenoemde map in mijn profiel. Voor de zekerheid heb ik ook weer "cert9.db" verwijderd en daarna Firefox opnieuw gestart: nu krijg ik ook in mijn gebruikelijke profiel een certificaatfoutmelding als ik https://community.t-mobile.nl/ open.

[*] Firefox maakt een schone versie hiervan automatisch aan bij opstarten. Verwijderen van bestanden moet je natuurlijk doen als Firefox niet draait. Mocht je dit soort experimenten willen doen, maak dan eerst een voledige back-up van alle bestanden in jouw profiel.


Kortom, een Firefox gebruiker met een bestaand profiel, die niet toevallig het nieuwe intermediate certificaat in de certificate store heeft, zal een certificaatfoutmelding krijgen zodra deze https://community.t-mobile.nl/ opent.

Misschien ten overvloede, maar er bestaat (ook) een certificaat-checker op
https://check-ocsp.quovadisglobal.com/
Als ik daar het serienummer van het betreffende intermediate certificaat (copy-paste) invul en op "check OCSP" klik,
blijkt het zonder twijfel een revoked certificaat te zijn.

Ik denk dat het volgende 'nieuws' van een maand of 4 geleden ermee heeft te maken dat we geen error (in Firefox) zien:
https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/

@Erik

Goed werk, nu met een schone Linux VM en gewacht tot services.settings.security.onecrl.checked een waarde != 0 had en dan krijg ik ook de SEC_ERROR_REVOKED_CERTIFICATE op Firefox 86.0

Het zelfde spelletje op Firefox-esr 78.8 met het zelfde resultaat.


Ik moest overigens wel een dikke 10 minuten wachten voordat FF dat ONECRL bestand gedownload had.

Het data.safe.bin bestand is in mijn laatste geval 571801 bytes groot en staan in $HOME/.mozilla/firefox-esr/$profile-name-esr78/security_state

Als we dan toch met OCSP bezig zijn:

In geval van "security.OCSP.enabled":
= 0: maak geen gebruik van OCSP (maakt het snelst verbinding, maar is riskanter, tenzij je gebruik maakt van OCSP-stapling van bezochte server waarbij je dan wel zeker moet weten dat de bezochte server OCSP-stapling ondersteunt)
= 1: fetch OCSP for DV and EV certificates (altijd certificaatcontrole bij https)
= 2: fetch OCSP only for EV certificates (uitblijven van OCSP-controle leidt tot iets sneller contact met meestal minder belangrijke servers die geen EV-certificaat gebruiken, maar controleert bijv. in de meeste gevallen wel sites waarmee je doorgaans altijd gevoelige informatie uitwisselt, zoals bijv. je bank (d.w.z.: sites met een EV-certificaat!)

> security.ssl.enable_ocsp_stapling = true : maakt voor OCSP-controle gebruik van de server die je bezoekt
(= privacyvriendelijker, maar werkt alleen als de server die je bezoekt OCSP-stapling ondersteunt!)
> security.ssl.enable_ocsp_stapling = false : maakt nooit gebruik van OCSP via de server die je bezoekt.

> security.ssl.enable_ocsp_must_staple= true : vereist correcte respons van de server bij gebruik van stapling
(waarschuwing bij geen correcte OCSP respons)
> security.ssl.enable_ocsp_must_staple= false : vereist geen correcte respons bij gebruik van stapling via de server
(dus geen waarschuwing als er geen correcte OCSP-respons van de server komt, en alles gaat verder gewoon door)


(correct me if I'm wrong, en vul eventueel aan wat nog ontbreekt)

Dat denk ik niet aangezien de -ESR versies het zelfde gedrag vertonen.

@Anoniem gisteren 20:49: dank voor de OCSP aanvullingen!

Ah, ook dat wist ik nog niet, dank voor deze link! Dit verklaart ook waarom ik de nieuwe versie van het certificaat terugvond in het "data.safe.bin" bestand in mijn gebruikelijke Firefox profiel onder Windows, en geen foutmelding kreeg bij het openen van de T-Mobile community site. Overigens lijkt het erop dat de in Firefox ingebouwde certificate manager (sowieso een onding) preloaded intermediate certificaten (kennelijk toegevoegd aan "data.safe.bin") negeert.

Aanvulling: wellicht maakt Firefox voor Android nog geen gebruik van de techniek om intermediate certificaten te preloaden (in aanvulling op de OneCRL techniek voor het blocklisten van ingetrokken certificaten, iets dat duidelijk wel door Firefox voor Android wordt gebruikt). Dat zou verklaren waarom ik met Firefox op mijn Android smartphone (een browser die ik veel gebruik) wel een certificate-error kreeg en in Firefox onder Windows niet.

Dank voor jouw testwerk en de bevestiging van mijn bevindingen! De vraag is nu hoe lang we moeten wachten tot Firefox de nieuwe versie van het intermediate QuoVadis certificaat heeft "gepreload".

Al met al maken deze trucs van Mozilla het foutzoeken er niet gemakkelijker op, en ook is dit niet motiverend voor serverbeheerders om het juiste intermediate certificaat mee te sturen. Het is in elk geval geen goed idee om met jouw eigen browser te checken of jouw webserver goed geconfigureerd is. Advies: gebruik daarvoor een site als ssllabs.com!

Ik dank jou, omdat het me aanspoorde om te vinden wat ik zelf al een hele tijd nog maar half begreep.
En ik dank security.nl, omdat het hier nu kort maar krachtig op een rijtje mag staan.

Dat klopt! Mozilla schrijft er o.a. dit over:
(dit en meer over intermediate certificate preloading op:
https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading)

Uit de zonet laatstgenoemde url hier direct boven blijkt dat de nieuwe methode is geïntroduceerd in Firefox 75.
De momenteel meest recente ESR-versie is gebaseerd op Firefox 78.
78 komt na 75, dus het klinkt logisch dat de huidige ESR-versies hetzelfde reageren als de niet-ESR versies sinds versie 75. Maar de oudere 68.x ESR versies zouden dit gedrag niet moeten vertonen.

Geachte lezers van postings in deze draad,

In de volgende draad (zie onderstaande link) reageerde Erik van Straten ook met een verwijzing naar de draad hier:
https://www.security.nl/posting/695566/Internet_nl+biedt+verbeterde+testen+voor+TLS+en+Content+Security+Policy

Ik verwijs hier met name naar om het hele verhaal onder een en dezelfde noemer te houden en mede als 'kruis-verwijzing'.
Nogmaals dank aan Erik van Straten voor de "heads-up" aangaande revocatie in samenhang met de missers in scans.

Ga nooit zonder meer uit van de validiteit van bepaalde scan-resultaten,
zonder dat je dit zelf buiten twijfel meent te hebben vastgesteld.

Hierboven is dat wel weer een keertje ondubbelzinnig bewezen. QED.
De houding hierin van Erik van Straten meen ik de juiste te zijn.

luntrus