Als je niet weet hoe je een certificaat chain bekijkt raad ik je aan Windows opnieuw te installeren met alle standaard instellingen zoals elke andere beginner.
Succes!

Ik kan me nog voorstellen dat er iets mis zou zijn met de Windows certificate store, maar aangezien Firefox z'n eigen certificate store heeft denk ik niet dat het probleem in de certificate stores van de betreffende PC zit.

Ofwel iemand heeft een MitM proxy geïnstalleerd zonder jou dit te vertellen en het certificaat daarvan is niet op jouw PC terechtgekomen, ofwel jouw PC heeft andere proxy-instellingen dan werkende PC's (en komt uit op een MitM proxy). Ofwel de klok staat goed, maar de datum niet...

Je kunt in Firefox toch gewoon het ontvangen certificaat openen, en vervolgens de certificate chain bekijken? Het root certificate voor security.nl is "GlobalSign Root CA" en het huidige certificaat van security,nl zelf heeft een SHA1 Fingerprint van "4D:21:FC:69:AE:19:AC:56:98:2B:F1:CF:09:CB:5F:01:2E:1A:FB:75" (Firefox toont deze met dubbele punten tussen de hexadecimale bytes).

Check je datum en tijd op de pc, als die niet goed staan krijg je ook rare situaties

Ik heb dit een keer gehad toen er een of ander beveilingsproduct op mijn PC stond die zelf eigen certificaten gebruikte om alles te versleutelen. Ik weet de naam niet meer, maar het was een redelijk standaard en bekend product.

Misschien wordt je verbinding getapt en ssl verkeer automatisch on the fly ontsleuteld (geen handmatige attack waardoor je de fouten ziet) ?

ik zou haast zeggen dat squid verkeerd ingesteld is worden, ik had daar ook een probleem mee, vraag me niet wat ik deed om het te fixen, want ik gebruik het niet meer, omdat bepaalde sites vol over de zeik gingen met de proxy.

Hoogst waarschijnlijk een probleem met Squid Proxy:
https://smoothnet.org/squid-proxy-with-ssl-bump/

PressBrainsHarder

Helaas staat er nog niks bij wat in de richting van het probleem wijst. Ik weet goed wat er in het netwerk (en squid)
gebeurt (er is geen SSL bump ofzo actief), en zoals ik al schreef, met andere PC's werkt het wel. En het is een schone
Windows 10 install vanaf de DVD. Niks aan producten geinstalleerd behalve dan Firefox en Chrome in een poging om
te testen of alleen Edge dit probleem heeft.
Ik had ook verwacht dat Firefox gewoon zou werken maar dat is dus niet zo, wellicht dat die inmiddels ook de Windows
routines gebruikt ipv openssl want de foutmeldingen zijn gewoon hetzelfde als bij de andere 2 browsers.
Inderdaad, in Firefox kun je nog wel kijken (dit soort dingen wordt steeds moeilijker gemaakt in de meeste software),
ik zal maandag eens kijken of ik daar verder mee kom. In de foutmelding zelf is niks aanklikbaar voor meer detail,
zoals vroeger wel het geval was.

Misschien omgeleid via Kazakstan? https://www.security.nl/posting/617785/Kazachstaanse+providers+onderscheppen+https-verkeer

Niet alleen in Kazakstan ;-)

Krijg je wel het oorspronkeleijk certficate te zien wanneer je het certificate bekijkt?
Zo nee, wat voor cert krijg je dan? Self Signed oid?

Ok ik heb er weer eens mee getest en ik merk nu dat het met Firefox wel gewoon goed werkt. Wellicht dat dit
wisselt per domeinnaam, maar ik zie nu even geen domeinen waar het mee fout gaat. Bijvoorbeeld nos.nl geeft
keurig een groen slotje en alles in orde, geen meldingen. Als ik op het slotje klik krijg ik de SSL informatie vanuit
Firefox zelf, dat is dus nog wel zoals het altijd was.

Echter met Edge en Chrome gaat het fout. Als ik daar een verbinding met nos.nl maak krijg ik meteen weer die
foutmelding, en dan kan ik doorgaan naar de site. Met bijvoorbeeld Google kan dat niet omdat ie dan zegt dat
het verboden is die error te negeren omda tde site HSTS gebruikt.

Kijk ik bij nos.nl naar het certificaat dan krijg ik een tree van 3 lagen die begint bij Comodo RSA Certification
Authority en daar staat een geel driehoekje met uitroeptekentje in en de melding "de verlener van dit certificaat
kan niet worden gevonden". Maar die moet toch in de root certificate store van windows staan??
Als ik daar kijk dan staan er wel een stuk of wat uitgevers en een aantal van Microsoft, plus dus die ene van ons
domein, maar niks van Comodo.
Vroeger was er altijd een regelmatig terugkerende Microsoft Update die dit bijwerkte. Maar de machine is
geupdate, echter dit is kennelijk niet gebeurd. Hoe kan dat? Weet iemand hoe dat tegenwoordig werkt?

Staat je tijd/datum goed?

Batterij in PC vermoedelijk leeg. Datum/tijd staan niet goed.

Werkt je crl check goed?

Ik zie allerlei irrelevante vragen en opmerkingen maar ik wil het graag houden bij het gestelde in de startpost en het
antwoord om 14:28 (op 22 juli) waarin ik aanvullende testresultaten en bevindingen geef.

Op internet zoekend zie ik wel meer mensen die dit probleem hebben (niet veel) maar helaas is er nergens een
1-staps oplossing te vinden. Ik kan bijvoorbeeld zoals beschreven met certutil de hele lijst van vertrouwde
certificaten ophalen van Windows Update en dan krijg ik een stuk of 400 .crt files maar die zou ik dan een voor
een moeten importeren ofwel met de GUI ofwel met een zelf te fabrieken Powershell script ofzo.

Maar dat kan toch niet nodig zijn? Die certificate store hoort toch automatisch gevuld en onderhouden te worden?
Dat certutil commando is ook enige tijd bezig en download daadwerkelijk die certificaten (als 1 groot bestand) om ze
daarna uit te pakken, dus kennelijk is die machine wel in staat dat de doen (netwerkgewijs). Waarom doet ie dat
dan niet, zoals normaal wel gebeurt? Daar ben ik nog niet achter.

Komt het omdat hij achter een proxy zit? (die wel geconfigureerd is, zowel in Edge als in "netsh winhttp set proxy")
Komt het omdat hij in een domein zit? (zou daar ergens ingesteld kunnen zijn dat hij geen root certificates moet downloaden)

Daar heb ik meer aan dan gezanik over de klok of over Kazachstan.

Probeer eens certmgr.msc en dan kijk je bij trusted root Certification Authorities, zijn de verloop datums wel in de verre toekomst?
En check de tijd inderdaad dat kan ook wel eens voor rariteiten zorgen.
Waar heb je je install image vandaan? Misschien rommel meegekregen?

Ik vraag me af waarom ondanks dat er in mij startpost staat "De klok staat goed. Hij zit in een domein."
(2 keer bevestiging dat de tijd OK is) toch steeds weer mensen vragen of de klok goed staat... als je in een
domein zit wordt de tijd automatisch gesynchroniseerd en als dat niet goed gaat heb je wel grotere problemen
dan waar in nu mee tob (Kerberos, weet je wel?).

Het is gewoon een schone install van een Microsoft DVD image. Ik ga er voor 100% van uit dat het geen
kwestie is van rommel of AIVD of wat de mensen hier ook denken maar gewoon iets met betrekking tot de
werking van Windows 10 in combinatie met een domein of een proxy wat ik niet begrijp en waarvan ik gehoopt
had hier wat expertise aan te treffen.

Ik weet niet uit m'n hoofd onder welke omstandigheden domein-PC's terugvallen naar NTLM, maar ik vermoed dat Microsoft wel iets zal goochelen als een wat oudere domein-PC met lege CR2032 o.i.d. wordt aangezet. En, zoals ik tussen de regels door eerder schreef, de tijd boeit niet (ok zelden), het gaat vooral om de datum.

Verschillende mensen hebben de tijd genomen om jouw bijdrage te lezen, op basis van de zeer summiere details in te schatten wat er zou kunnen spelen, en een reactie te posten. Ik raad je aan voortaan de gangbare netiquette regels aan te houden. Denk aan eerder reageren als je een vraag stelt of aankondigen wanneer je daar weer tijd voor hebt, en inhoudelijk te reageren op voorgestelde handelingen. Dat zal je veel meer zinvols opleveren (onze tijd is, net als die van jou, ook kostbaar). Einde preek.

Welk certificaat van deze site (security.nl) zie je op de betreffende PC? (Zie mijn vorige bijdrage). Als dat het juiste certificaat is (met foutmelding) dan wordt TLS niet ge-MitM-ed en kunnen we focussen op waarom de validatie niet goed gaat. Als dat een vals certificaat is, is er zeker sprake van een MitM (en kun je wellicht met WireShark kijken wat er fout gaat).

Aanvulling: de draad terugkijkend zie ik dat enkele bijdragen, die mogelijk van jou zijn, later zijn toegevoegd (dat krijg je als je anoniem post). Tip: maak een account aan, of begin je bijdagen met "TS hier".

Firefox heeft z'n eigen certificate store. Firefox kan (sinds kort of nog net niet) rootcertificaten uit de Windows certificate store overnemen (https://www.security.nl/posting/615285/Firefox+verhelpt+tls-foutmelding+die+antivirus+veroorzaakt). Opgeslagen HSTS informatie (die verhindert dat je het certificaat kunt bekijken) kun je verwijderen door Firefox geheel te sluiten, de file " SiteSecurityServiceState.txt" in het profiel te verwijderen en Firefox te herstarten (profielmap: c:\users\naam\AppData\Roaming\Mozilla\Firefox\Profiles\*.default).

Intermitterend gedrag zou erop kunnen wijzen dat er een netwerkprobleem is (asymmetrische routering wellicht). Check ook op duplicate IP-adressen. Een duplicate MAC adres leidt helemaal tot bizarre waarnemingen - en dat kan ook gebeuren als er malware op je netwerk zit en iemand met ARP-spoofing zit te klooien. Het zou wellicht ook nog om een defecte NIC (buffergeheugen daarin) of zelfs switch (poort) kunnen gaan.

Ik heb zaterdag al aangegeven dat ik er maandag weer naar zou kijken (het is werk, weet je) en maandag mijn
bevindingen geplaatst inclusief dat ik geconstateerd heb dat de root certificate lijst bijna leeg is.
Het is dus niet nodig verder te bazelen over klok en MITM enzo, houd het een beetje bij het onderwerp aub.

Vandaag ben ik verder gegaan met onderzoeken hoe het kan dat die root certificaten er niet op staan maar daar
ben ik niet uit gekomen. Ik heb wel gezien dat het ding ondanks dat er een proxy op geconfigureerd is de hele
tijd aan het proberen is te connecten naar Microsoft en Akamai. Wellicht heeft het feit dat hij niet direct naar
internet kan (en men te lamlendig is om fatsoenlijke proxy support in het systeem in te bouwen) dit probleem
veroorzaakt. Nu nog een oplossing vinden... liefst een oplossing van een of enkele stappen, niet het installeren
van 400 certificaten (met dan nog het risico dat die niet worden geupdate).

Ik snap niet hoe het kan dat WIndows Update WEL werkt, maar het installeren van root certificaten (wat volgens
de experts op de microsoft forums via windows update zou gaan) kennelijk niet. Wat ik ook niet snap is dat na
een install de root certificate lijst bijna leeg is (16 certificaten), je zou toch verwachten dat er een flinke set
in staat die hooguit deels verouderd is. Die dingen hebben norrmaal gesproken een geldigheid van meerdere
jaren.

Ik heb nog geprobeerd hem even op een open netwerk aan te sluiten maar dat heeft het (nog) niet opgelost.
Hij maakte wel een flink aantal connecties maar heeft kennelijk niet meteen die certificaten opgehaald waar hij
zo met smart op zat te wachten. Ik denk dat het alleen informatie insturen naar Microsoft betreft.

Interne WSUS server wellicht?

Overigens worden CRL's via http opgehaald, wellicht (weet ik niet uit m'n hoofd) worden rootcerts ook via http (als signed cab file) gedownload. Kan de PC wel via http naar buiten?

Nee dat niet. Hij doet gewoon zelf zijn windows update, via de proxy. En dat werkt al vanaf het begin OK.
Ja, via de proxy.
Het enige wat ik me kan indenken is dat er ergens iemand een rot stukje code heeft afgeleverd waardoor het niet via
de proxy gaat. Echter in Windows is dat probleem er (in tegenstelling tot Linux) normaal gesproken niet, omdat de
standaard bibliotheken (winhttp) standaard proxy support hebben zodat de applicaties dat niet zelf bij elkaar hoeven
te sprokkelen en -configureren. (in Linux heeft elk programma daar zijn eigen oplossing voor)

Ik heb vele jaren Windows machines op dit netwerk geinstalleerd en beheerd t/m Windows 8 en dat werkte altijd goed,
maar nu met deze Windows 10 machine werkt het dus niet. Er moet ergens wat fout zijn gegaan bij de installatie.
Maar ik zou toch denken dat als je een machine installeert met totaal geen netwerk connectivity, dat ie dan toch wel
een standaard set rootcertificaten zal installeren. Kennelijk toch niet, maar slechts een stuk of 16. De rest moet dan
van Windows Update komen blijkbaar. Echter hij heeft gewoon die hele component update van oktober afgelopen jaar
geinstalleerd zonder mokken en nog zitten die certificaten er niet in.

Als ik "certutil -syncwithwu c:\windows\temp" doe dan krijg ik keurig die certificaten binnen maar ja dan zet ie ze dus
in die directory neer, niet in de store. Ik zie geen command om ze dan meteen even te importeren. Ik denk dat dit
commando daar niet voor bedoeld is, maar voor debugging van het download mechanisme ofzo. maar dat werkt dus.

Ik weet niet in welk formaat ze dan gedownload worden, maar vermoedelijk werkt het volgende als de file authroot.stl heet (door http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab te downloaden en die .cab uit te pakken krijg je die file in elk geval. Die .cab werd ook, kort nadat ik W10 1903 had geïnstalleerd, gedownload zag ik zojuist in de wireshark capture die ik toen gemaakt heb, maar bij mij werd die file natuurlijk automatisch geïmporteerd):

- Start (als admin) certlm.msc
- Ga naar "Certificates - Local Computer" -> "Trusted Root Certification Authorities" -> "Certificates"
- Rechts-klik erop, kies "All Tasks" -> "Import"
- Kies voor alle soorten files en importeer authroot.stl

Als dat werkt zouden de certificaatfoutmeldingen weg moeten zijn, maar het blijft gek dat je die ook zag bij Firefox.

Gevoelsmatig denk ik dat er iets is misgegaan bij de installatie op jouw PC (iets corrupt geraakt is) of dat er ergens een hardware probleem speelt wat deze gekkigheid veroorzaakt. De vraag is of de PC, als ie ooit een nieuw rootcert nodig heeft, deze dan wel automatisch zal downloaden. Als check kon een herinstall wel eens het minste werk zijn...

Aanvulling: voor wat meer info zie bijv. http://woshub.com/updating-trusted-root-certificates-in-windows-10/

Met het bovenstaande commando krijg je een directory vol met .crt files.
Dat zijn alle vertrouwde root certificaten volgens mij, en wellicht ook nog wel wat tussenliggende.
(Microsoft heeft er een handje van om onnodige 2nd level certificaten in de root store te zetten, met lastig te
pinpointen problemen voor anderen als gevolg, met name als ze nun certificaat niet goed installeren)

Ik denk dat die download dan door een apart tooltje gedaan is wat geen proxy ondersteunt! Daarmee heeft mijn
computer die gemist natuurlijk...
Dat doet wel iets, maar niet wat ik verwachtte. Die file blijkt maar 139 k te zijn dus die bevat natuurlijk niet
alle certificaten. En inderdaad, nadat ik die geladen heb komt er maar 1 ding bij, iets van een "Microsoft
vertrouwde certificatenlijst". Ik denk dat het alleen de lijst is en niet de certificaten zelf. Dus er verandert
verder niks aan het probleem.

Nee dat was een foutje in de startpost, dat heb ik later ook gecorrigeerd: het werkt in Firefox wel goed!
Het probleem is er alleen in Edge en Chrome. Maar omdat het meerdere verschijningsvormen kent en omdat
Chrome kennelijk ook de boel beduvelt (hij laat je wel een Google zoekscherm zien bijvoorbeeld maar als je dan
wat gaat zoeken dan is de verbinding ineens onveilig, kennelijk zit er een zoekscherm in Chrome ingebakken ofzo
waardoor je dat WEL te zien krijgt) en ik vanalles heb zitten testen heb ik dit kennelijk toen verkeerd gezien.


Ik heb het volste vertrouwen in deze (Dell Optiplex 5040) machine, hij heeft meer dan een jaar Linux staan draaien
zonder enig probleem en hij heeft nooit een foutmelding gegeven waarvan je denkt "oei, is de hardware wel betrouwbaar".
De install is gedaan van een DVD die gedownload is via ons Microsoft Premier account en ik vertrouw dat volledig.

Ik ga dan denk ik toch maar als workaround die rootcertificaten die gedownload zijn op een of andere manier installeren.
Wellicht dat het alleen een probleem is geweest dat er geen internet was vroeg in de installatie, misschien had ik hem
beter eerst op het gastennetwerk kunnen installeren en dan later overzetten naar het bedrijfsnetwerk en het domein
laten joinen.

Uiteraard bleek het toch nog wel simpel te zijn om die paarhonderd certificaten te laden (dat krijg je er van als je
te veel van dat soort websites leest van mensen die alleen Windows kennen, die bedenken zich dat soort dingen
niet...) door gewoon met een for loopje voor *.crt die tool "certutil -addstore -f root filenaam.crt" aan te roepen.
Na de lastige syntax van Windows for loopjes weer uit het geheugen opgediept te hebben werkte het en nu zijn
alle problemen opgelost.

Alleen de root cause nog niet, natuurlijk.

Sorry, mijn vorige bijdrage (gisteren bijgewerkt 23:24) klopt niet. Na wat uitzoekwerk het volgende.

1) authroot.stl (uit authrootstl.cab) bevat geen certificaten, maar metadata van (door MS) vertrouwde rootcertificaten.

2) By default staan maar een beperkt aantal rootcertificaten in het register en zijn daamee zichtbaar in "certlm.msc".

3) Verreweg de meeste certificaten staan in "c:\Windows\SystemResources\crypt32.dll.mun". Ik raad de TS aan om te checken of die file bestaat, en zo ja, of de signature klopt. Bestanden onder C:\Windows\ hebben meestal een detached signature, waardoor je geen signature tabblad ziet in de eigenschappen/properties van die file. Die signature kun je het makkelijkst checken met sigcheck.exe/segcheck64.exe van Mark Russinovich (zie https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck). Output bij mij:

4) Door te draaien: certutil -generateSSTFromWU roots.sst
wordt een file roots.sst gemaakt met daarin alle momenteel door Microsoft vertrouwde rootcertificaten. Terwijl ik dat deed (met Wireshark aan) zag ik dat eerst authrootstl.cab werd gedownload, en daarna 27 rootcertificaten afzonderlijk werden gedownload die kennelijk zijn toegevoegd of zijn vernieuwd t.o.v. wat er in crypt32.dll.mun zit.

5) Door op die roots.sst file te dubbel-klikken, wordt een certmgr instantie gestart. Daarin is te zien (in de statusbalk, onderaan), dat er 395 rootcertificaten in die file zitten.

6) Nu werkt het volgende (dit heb ik zelf zojuist getest, maar zie de "LET OP" hieronder):
- Start (als admin) certlm.msc
- Ga naar "Certificates - Local Computer" -> "Trusted Root Certification Authorities" -> "Certificates"
- Rechts-klik erop, kies "All Tasks" -> "Import"
- Kies voor alle soorten files en importeer roots.sst
In certlm.msc zijn daarna alle rootcerts te zien, volgens de statusbalk zijn dat 399 certificaten (dus 4 meer).

LET OP: hiermee worden ook een heel stel verlopen en zelfs revoked certificaten ingeladen! De enige reden die ik kan bedenken waarom Microsoft door de uitgever ingetrokken rootcertificaten als "vertrouwd" blijft beschouwen, is dat anders een heel stel authenticode-signed files ongeldig kunnen worden (het idee is dat zo'n signature geldig blijft als een of meer van de betrokken certificaten worden ingetrokken nadat de timestamp is toegevoegd aan de digitale handtekening).

7) Om te checken of er MEER rootcertificaten zijn geïnstalleerd dan "vertrouwd door Microsoft" kun je draaien:
sigcheck64.exe -tuv. Daarmee wordt ook (ongemerkt maar zichtbaar met wireshark) authrootstl.cab gedownload, en er wordt gemeld welke rootcertificaten er zijn geïnstalleerd die NIET in die authootstl.cab file voorkomen. Bij mij leidde dat tot de volgende output:

Die rootcertificaten hebben, volgens een zoektocht op internet, kennelijk iets te maken met XBox Live (waar ik helemaal niets mee doe) maar die zouden ook kunnen zijn toegevoegd door het bezoeken van de Windows Store. Kennelijk is het Client certificaat gebruikt voor het ondertekenen van een "Personal" IPSec certificaat dat maar 1 dag geldig is, en -notabene- een 1024bit RSA key bevat. Vies allemaal, ik ga die 2 roots verwijderen en ga in de gaten houden onder welke omstandigheden ze precies weer terugkomen (mocht dat gebeuren).

8) Daarna heb ik handmatig vergeleken welke andere twee rootcertificaten er in de "Trusted Root Certification Authorities" store op mijn PC zitten (te zien met certlm.msc) en niet in de roots.sst file:

A) OU = Copyright (c) 1997 Microsoft Corp.
OU = Microsoft Time Stamping Service Root
OU = Microsoft Corporation
O = Microsoft Trust Network
Geldig tot "Friday, 31 December 1999 01:59:59"
Thumbprint (SHA1): 245c97df7514e7cf2df8be72ae957b9e04741e85

B) CN = Microsoft Authenticode(tm) Root Authority
O = MSFT
C = US
Geldig tot "Saturday, 1 January 2000 01:59:59"
Thumbprint (SHA1): 7f88cd7223f3c813818c994614a89c99fa3b5247

Waarom die twee niet gemeld worden bij stap 7 hierboven is me nog een raadsel, want genoemde SHA1 hashes komen niet voor in een dump van authroot.stl (middels "certutil -dump authroot.stl"), terwijl SHA1 hashes van andere certificaten daar wel in voorkomen (met grep en uniq zag ik dat er in authroot.stl 395 unieke hashes staan, steeds achter "Subject Identifier: ").

Lijkt er sterk op dat het automatisch downloaden van root certificaten (was?) mislukt.

En natuurlijk de simpele vraag: werkt het (voor) nu ?

Ja daar was ik ook al achter gekomen en dat had ik al gemeld daarboven.
Wat precies het nut is van die lijst ontgaat me een beetje, ik had nog de hoop dat hij als je met een certificaat
aankomt wat wel in die lijst staat maar niet geinstalleerd is, dat automatisch zou installeren. Maar dat is dus niet zo.

Klopt, dat is het probleem waar dit topic over gaat. 22-7 om 14:28 heb ik dit voor het eerst gemeld als diagnose
van wat er fout is.

Die directory bevat hier niet dat bestand, maar die bevat ook totaal geen bestanden met een vergelijkbare
naamgeving. Sterker nog, die bevat geen enkel bestand, alleen maar directories.
Zelfs nu ik het inmiddels gefixed heb door al die certificaten te importeren.


Ok dat was dan wellicht de goede methode geweest want dan doe je het in 1 handeling.
Een stuk of 3 verschillende blog posts van allerlei mensen die ook dit probleem hebben die hebben deze
oplossing helaas niet gemeld en kwamen alleen met die oplossing die ik gebruikt heb waarbij zij dan vastliepen
op "dan heb je 400 crt files die je allemaal moet importeren" en waar ze als clickety-click beheerder natuurlijk
een probleem mee hadden, maar met een simpel for loopje was dat hier in 30 seconden gedaan.

Wat die verlopen en revoked certificaten betreft, daar maak ik me verder geen zorgen over, het gebruik wat
er van deze PC gemaakt zal worden daar is dat verder niet belangrijk voor.
(is toch meestal al geen probleem tenzij je bijzonder paranoide bent en bang bent dat je wordt aangevallen
via een onterecht door Diginotar oid uitgegeven certificaat, dat zal wel loslopen)

@TS: dank voor jouw antwoord!

Het lijkt erop dat Microsoft vanaf W10 versie 1903 allerlei resources, waaronder certificaten, uit DLL's heeft gehaald en die in separate files (met een .mun extensie erachter) in C:\Windows\SystemResources\ heeft geplaatst.

In elk geval in Windows 7 zie ik de certificaten gewoon nog in C:\Windows\System32\crypt32.dll zitten (met de ingbouwde viewer van Total Commander, bijv. zoeken naar de string AdminCA-CD-T01 - overigens een van de zowel revoked als verlopen certificaten). Wellicht draai je nog de vorige versie van W10 en staan er daarom bij jou geen losse bestanden in C:\Windows\SystemResources\.

Aanvulling: in de STL file zit aanvullende metadata. Als je bijv. in certlm.msc rechts op een certificaat klikt en properties/eigenschappen kiest, dan zie je dat je door vinkjes uit te zetten aanvullende restricties kunt opnemen (het rootcertificaat zelf verandert hier natuurlijk niet door, deze info zit vermoedelijk samen met het certificaat in "blobs" in het register, system certs onder HKLM\SOFTWARE\Microsoft\SystemCertificates\). Als ik het goed begrijp komen de default settings uit de STL file. Vermoedelijk kan Microsoft de mogelijkheden van rootcertificaten later desgewenst verder inperken, bijv. na compromise van een private key.

Ok ik gebruik nog de 1809 versie want de 1903 wil hij niet installeren. Niet uit zichzelf, en als ik dat handmatig probeer
te doen dan krijg ik "deze versie is nog niet beschikbaar voor jouw computer" of zo iets.
Ik denk dat er bedoeld wordt dat men deze nog niet uitrolt naar computers die in een domein zitten.
Dat zal ooit nog wel komen neem ik aan.