N.B.
Op 1 mei schreef ik dat de signature van het EMET 4.1 Update 1 installatiebestand ongeldig was.
Dat was uiteraard niet het geval. Er was wat mis met de verwerking van certificaten door mijn Vista systeem.
"Microsoft Root Certificate Authority 2010" ontbrak op mijn systeem, en na het corrigeren daarvan is er nog steeds wat mis. Ik zoek nog naar een oplossing. Zie de rest van de bijdragen in deze thread.

N.B.
Op 1 mei schreef ik dat de signature van het EMET 5.0 Technical Preview 2 installatiebestand ongeldig was.
Dat was uiteraard niet het geval. Er was wat mis met de verwerking van certificaten door mijn Vista systeem.
"Microsoft Root Certificate Authority 2010" ontbrak op mijn systeem, en na het corrigeren daarvan is er nog steeds wat mis. Ik zoek nog naar een oplossing. Zie de rest van de bijdragen in deze thread.

Zojuist "EMET Setup.msi" gedownload, signature klopt en timestamp van Authenticode signature is Tuesday, April 29, 2014 19:43:45.

File size = 8,620,032 bytes. SHA1=3da93a83d318d4401dd1af1a3a81ca963f7c72b8 (zie ook https://www.virustotal.com/en/file/148f84041938745eace1586f6a4ede8029cb424e4ba430d19a3af5c408dc4a9a/analysis/).

Download vond plaats vanaf 95.101.0.89 poort 80 om 13:09 +0200.

Ik noem expliciet het IP-adres vanwege de DDoS aanvallen tegen UltraDNS (zie https://isc.sans.edu/diary/UltraDNS+DDOS/18051). @Spiff: het is interessant te weten vanaf wel IP-adres je die EMET bestanden gedownload hebt. nslookup van download.microsoft.com levert bij mij op:

@ Erik van Straten,
Dankjewel voor je reactie.
Mooi dat in jouw geval de timestamp gewoon aanwezig is en klopt.

Zou Microsoft het dan inmiddels hebben gecorrigeerd, dacht ik?
Maar bij opnieuw downloaden van EMET 4.1 Update 1,
eenmaal via https://www.microsoft.com/en-us/download/confirmation.aspx?id=41138
en eenmaal via http://www.microsoft.com/en-us/download/confirmation.aspx?id=41138,
zie ik via Windows Verkenner in Eigenschappen, Digitale handtekeningen opnieuw dezelfde foutmelding als die ik hierboven weergaf.
Bij upload naar VirusTotal lijkt echter alles gewoon te kloppen, zie:
https://www.virustotal.com/nl/file/148f84041938745eace1586f6a4ede8029cb424e4ba430d19a3af5c408dc4a9a/analysis/1398947415/
Ik weet niet wat die discrepantie tussen de weergave in Windows Verkenner en door VirusTotal veroorzaakt.

Wat betreft het IP-adres waarvan download plaatsvond, daarbij heb ik wellicht even je assistentie nodig.
Hoe vind ik dat adres?
In mijn firewall logs vind ik diverse acties, hosts en poorten gerelateerd aan de betreffende download, maar ik kom er niet uit welke verbinding exact de download betreft.

Zijn je rootcertificaten wel in orde?

Ik begon het me ook af te vragen.
Hoe controleer ik dat precies?
N.B. En dan specifiek voor een Vista (Ultimate) systeem, omdat dat misschien kan afwijken van Windows 7 of 8.x.

Denk dat je hier een punt hebt, zijn eind maart / begin april een hoop wijzigingen geweest met betrekking tot de root certificaten (verschillende 1024 certificaten ingetrokken, waardoor delen van website / downloads niet meer geldig zijn.) 2048 bits certificaten opnieuw uitgedeeld. Als jij nu nog een oud 1024bits root certificaat hebt in je certificate autority, en je download een file, dan heb je dus een mismatch, maar dat komt omdat jij dan geen nieuw 2048 root certificaat hebt.

De nieuwe root certificaten zijn rond 8april met windows updates uitgerold. (tevens er na na een fout ook weer ingetrokken, en hergepublischeerd, maar de fout moet je volgens mij zelf handmatig herstellen, even googlen)

Wij hebben er iedergeval al een hoop ellende mee gehad bij klanten. Succes

Als je de eigenschappen van het installatie-pakket aanklikt heb je daar een tabblad "handtekeningen" als je vandaar uit via "details" en "bekijk certificaat" naar "certificeringspad" gaat kun je zien of dat helemaal klopt (geen rode gevarendriehoekjes, dacht ik).

Je bent in ieder geval niet zo'n zeur die Vista niks vindt. Want dat viel na Sp1 best wel mee (als je tenminste geen Linux-adept bent ;-) . Heb het zelf jarenlang gebruikt. En eerlijk gezegd: "ik zie niet veel verschil met W7"

Dat is allemaal okee.
Het enige dat afwijkt is het ontbrekende "Tijdstip van handtekening" onder "Gegevens van de ondertekenaar", merkwaardig genoeg.

Klopt.
En op enkele punten vind ik Vista zelfs mooier en handiger dan Windows 7.
En op dezelfde hardware is Vista SP2 nog slechts een paar procent logger dan Windows 7.
Ik heb nog wel een Windows 7 licentie liggen, waarmee ik Vista een keer wil vervangen, gekocht toen de ondersteuning voor Vista nog leek af te lopen per april 2012, maar doordat de ondersteuning is verlengd naar 2017 en door drukdrukdruk ben ik nog nooit toegekomen aan een installatie van Windows 7 op dat systeem :-)

Hmm. Vreemd. Temeer daar Virustotal kennelijk wel het juiste bestand ziet. Zou er iets met de certificeringsmodules aan de hand zijn. Draai eens een "SFC /Scannow"

@Spiff: omdat de SHA256 hash (ook te zien in de VirusTotal URL) identiek is van de files die wij beiden gedownload hebben, is het zo goed als zeker dat het om hetzelfde bestand gaat. Er is dus geen sprake van server spoofing (door bijv. een DNS aanval), er is duidelijk iets aan de hand op jouw PC.

Om uit te sluiten dat het een probleem in Verkenner is zou je SigCheck kunnen downloaden (http://technet.microsoft.com/en-us/sysinternals/bb897441) en in een command prompt bijv. draaien als volgt:
Zien welke certificaten aanwezig zijn (zowel op je systeem als jouw persoonlijke account) is het makkelijkst door te starten:
Voor de file zelf heb je nodig: "Microsoft Root Certificate Authority 2011", en voor de timestamp: "Microsoft Root Certificate Authority 2010". Het zou mij verbazen als je die niet hebt. In elk van de "ketens" is sprake van 1 intermediate certficaat die zo te zien worden meegestuurd in het bestand.

Hoewel er hier dus geen sprake is van een vervalste server: het meest betrouwbaar kun je het IP-adres van de server waar je van downloadt vaststellen met een netwerksniffer (zoals Wireshark). Met "boordmiddelen" kan ook, maar het is wat uitzoekwerk: tijdens download van de file in een command prompt venster "netstat -no" (evt. meerdere keren achter elkaar) geeft vaak wel uitsluitsel over het IP adres (en poortnummer) waar de file vandaan komt.

Edit 2014-05-01 17:50: certvwr.msc (fout) gewijzigd in certmgr.msc

System File Checker uitgevoerd.
Geen schendingen van de integriteit gevonden.

Goed zo, u heeft allen weer de nieuwste NSA backdoor geinstall.
;)

Met Sigcheck ben ik nog wat aan het worstelen.

In welke map/ op welke locatie plaats ik sigcheck.exe bij voorkeur,
en uitgaande van die locatie, hoe voer ik het commando dat je aanreikte dan uit, uitgaande van Command Prompt
C:\Windows\system32>

Hoort dat onderdeel te zijn van Windows? Ook van Windows Vista?
Ik vind het echter niet.
Zit er mogelijk een spelfout in certvwr.msc, of is het geen standaardonderdeel van Windows Vista?

Ik zal het eens proberen met netstat -no

Gezien het feit dat ik nog worstel met Sigcheck en ik certvwr.msc niet vond, gaat een en ander nog wel even duren.

Wie de nieuwste EMET versies heeft geïnstalleerd, bedoel je?
Ha, dan mag je er wel van uitgaan dat zo'n backdoor met een eerdere versie ook al bestond.
En dan kun je wellicht beter helemaal geen Windows gebruiken zo lijkt me (of zelfs beter helemaal geen computer).

Ik heb de materie toentertijd gevolgd, en meende dat ik niets handmatig hoefde te herstellen.
Maar ik kan me natuurlijk vergissen, daarom bedankt voor de suggestie, Anoniem.
Maar je suggestie "even googlen" is wat érg algemeen. Kun je misschien een indicatie geven van de relevante zoektermen betreffend dit issue, zodat ik weet waarnaar te zoeken? Nogmaals bedankt.

In een map die in PATH voorkomt, bijv. C:\Windows\ (of maak een map C:\Utils\ aan en voeg die toe aan PATH).
In de command promt CD je vervolgens naar de map waar het bestand staat dat je wilt testen.

Sorry, ik heb CertMgr.msc en EventVwr.msc door elkaar gehaald! Het moet dus zijn: Ik zal dat in mijn vorige bijdrage ook even corrigeren.

"Microsoft Root Certificate Authority 2011" is aanwezig.
"Microsoft Root Certificate Authority 2010" vind ik niet.
Wel "Microsoft Root Certificate Authority".

Hmm, opvallend toch wel,
want ook nu: "De digitale handtekening van het object kan niet worden gecontroleerd."

Ik zie nergens een 5.0 Technical preview 2

Daar moet je jezelf voor aanmelden bij Microsoft Connect. En de File Transfer Manager installeren.
Is echt een beetje bedoeld voor techneuten die op voorhand een beetje met beta's willen stoeien.

Hmm. Dan is de foutmelding van SigCheck ook te verwachten.

Zou registry corruptie kunnen zijn. Je kunt regedit starten en kijken of de key (linkerdeel van het venster) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\3B1EFD3A66EA28B16697394703A72CA340A05BD5 bestaat.

Die 3B1EFD3A66EA28B16697394703A72CA340A05BD5 is de SHA1 hash van "Microsoft Root Certificate Authority 2010".

Als je links zo'n key selecteert is rechts een "Value name" genaamd "Blob" te zien van het type REG_BINARY. Zie je die?

Overigens, het ontbrekende certificaat kun je hier downloaden: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/3B1EFD3A66EA28B16697394703A72CA340A05BD5.crt - echter, een rootcertificaat downloaden via http en dan installeren is natuurlijk hartstikke link (toen ik deze zojuist downloadde was deze identiek aan het bij mij geïnstalleerde certificaat, maar of dit straks nog zo is, en of je mij en security.nl kunt vertrouwen?).

Er IS een check die je kunt uitvoeren: als je die file downloadt, deze opent middels dubbelklik, het certificaat exporteert als "MicrosoftRootCertificateAuthority2010.der" (binair formaat), en van die file de SHA1sum uitrekent, moet dat weer 3b1efd3a66ea28b16697394703a72ca340a05bd5 opleveren. Dit is wel een beetje goochelen natuurlijk, en zo hoort het niet te werken; Vista hoort automatisch ontbrekende root certificaten op te halen (hopelijk veilig).

Het kan ook zonder het installeren van de File Transfer Manager, door de (andere) download-optie te kiezen.
Wel heb je een Microsoft-account nodig, maar dat kun je aanmaken met nickname en bijvoorbeeld een mailinator-adres, als je dat verkiest.

Die key is niet aanwezig.
Hoort die key en "Microsoft Root Certificate Authority 2010" werkelijk aanwezig te zijn onder Windows Vista SP2?
Is het mogelijk dat dit voor Vista anders is dan voor bijvoorbeeld Windows 7?
Van welk systeem ging je uit?

Wel voor de andere keys, maar de key die je noemde is niet aanwezig.

Is dat certificaat dan niet via https te downloaden?
Door het Microsoft Download Center te benaderen via https://www.microsoft.com/en-us/download/ en dan te zoeken naar Microsoft Root Certificate Authority 2010, zou ik denken?
Maar nee, daar vind ik het niet, zie ik.
Hoe en waar had jij die Microsoft Root Certificate Authority 2010 download gevonden? Is hetzelfde niet via https in plaats van http te doen?

En ten slotte,
als het zo is dat Microsoft Root Certificate Authority 2010 werkelijk aanwezig hoort te zijn onder Windows Vista, waarom zou het dan niet automatisch opgehaald worden?
Bestaat er een kans dat m'n firewall dat blokkeert, door iets dat ik ooit verzuimd heb toestemming te geven?

Van Windows 7 maar dat root certificaat wordt ook al enkele jaren onder XP geïnstalleerd als je de laatste root cert update daarvoor downloadt (http://support.microsoft.com/kb/931125).

Ik heb gegoogled naar 3b1efd3a66ea28b16697394703a72ca340a05bd5 en vond die URL ergens in http://www.trojaner-board.de/125170-weisser-bildschrim-modzilla-start.html. De gevonden URL wijzigen in https levert een foutmelding op omdat de server (in mijn geval) a248.e.akamai.net heet.

Ik heb geen idee. Als ik het goed begrijp (maar ik kan me heel goed vergissen) wordt door Vista en later http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab gedownload als een root certificaat ontbreekt.

Als ik die file met de hand download, "authroot.stl" daaruit haal en die open door dubbel-klikken, zie ik onder "Trust List" (in mijn Engelstalige Windows) dat op positie 6 "Microsoft Root Certificate Authority 2010" staat. Die kan ik vervolgens bekijken en zien dat de thumbprint (hetzelfde als SHA1 hash) klopt (3b1efd3a66ea28b16697394703a72ca340a05bd5 met spaties tussen de bytes).

Nb. als ik "authroot.stl" open krijg ik een melding dat het certificaat gebruikt voor het ondertekenen van die lijst ongeldig is, maar ik vermoed dat dit een bug is in de default Windows certificate viewer. Als je nl. naar het certificaat zelf kijkt staat er "This certificate is not valid for the selected purpose". Er is uitsluitend een "Enhanced Key Usage" en de waarde daarvan is "Root List Signer (1.3.6.1.4.1.311.10.3.9)". Een "Key Usage" waarde ontbreekt. Ik vermoed dat de default Windows certificate viewer dit soort certificaten niet begrijpt (is ontworpen voor "gewone" digitale handtekeningen).

Als Microsoft Update werkt bij jou, zou dit ook moeten werken, vermoedelijk zit er iets anders in de weg.

Bij het Googlen (o.a. naar "Microsoft Root Certificate Authority 2010" - inclusief de dubbele aanhalingstekens) heb ik wat aanwijzingen gevonden dat er iets in een CryptnetUrlCache directory kan blijven "hangen". Kijk eens of je de foutmeldingen genoemd in http://support.microsoft.com/kb/2328240 terugvindt (die pagina begint met server maar verderop wordt ook Vista genoemd).

Googlen naar: missing "Microsoft Root Certificate Authority 2010" laat zien dat jouw probleem wel eens meer lijkt voor te komen.

@ Erik van Straten,
Heel hartelijk bedankt voor alle moeite die je neemt.

Het installeren van KB931125, Update for Root Certificates for Windows Vista, van november 2013,
zoals hier vermeld http://support.microsoft.com/kb/931125/en,
dat leek me een verstandige zet.
Bedankt voor de tip.
Microsoft EMET Feedback gaf dezelfde tip.
Het downloaden via de enige mogelijkheid die daartoe wordt geboden voor Vista en nieuwer, via de "Microsoft Update Catalog", dat was knap irritant. Er moest een ActiveX element voor geïnstalleerd worden, en het selecteren van een downloadmap lukte enkel vanuit een Administrator-account, maar goed, dan heb je ook wat, denk je.
Denk je.
Het bestand X86-all-rootsupd_2f61a0a102b7aededed0362ab4fd023d2016f5f0.exe lijkt zich niet uit te laten voeren, of het doet niet wat het doen moet. Na het geven van UAC-toestemming gebeurt er niets, lijkt het. Merkwaardig!
In ieder geval vind ik geen nieuw geïnstalleerde KB931125 onder de geïnstalleerde updates, en EMET 4.1 Update1 en EMET 5.0 Technical Preview 2 blijven weergegeven zoals ik aan het begin van deze thread aangaf.

Een dergelijke foutmelding met Microsoft-Windows-CAPI2 heb ik niet in de logboeken gevonden

Eventjes webzoekend met "Microsoft Root Certificate Authority 2010", zie ik dat Windows 7 gebruikers doodleuk "Microsoft Root Certificate Authority 2010" voor XP installeren,
via http://www.microsoft.com/en-in/download/details.aspx?id=38918
en met succes, zo lijkt het.
Is dat te overwegen, of kolder?
Mij lijkt het een recept voor problemen, een OS-vreemde update installeren, maar ik kan me vergissen.

Verder,
het onderzoeken van de EMET downloads door middel van netstat -no, daar ben ik niet meer aan toegekomen, en het lijkt me ook niet meer relevant, gezien dat ontbreken van "Microsoft Root Certificate Authority 2010", wat het probleem zal zijn.

Dat "Microsoft Root Certificate Authority 2010" probleem daar moet ik morgen maar mee verder.
Heb je nog goeie tips, Erik van Straten, of iemand anders, ik verneem het heel graag.
Bedankt alvast.


(Voor nu moet ik nog even elders verder met een flink probleem met de Microsoft noodpatch voor het IE-lek, dat verliep niet goed op m'n Vista systeem. M'n eerste slechte ervaring met een update voor Vista.
Argh... lekker dagje.)

Ben zoiets ook al eens tegengekomen bij een klant. Wat bij haar het probleem was:

MSconfig -> services -> staat Cryptsvc ingeschakeld?

Ja.

CryptSvc, Cryptographic Services
Opstarttype: Automatisch
Status van service: Gestart

Zou dat het probleem kunnen veroorzaken, bedoel je, of wanneer die service uitgeschakeld zou staan?

Dit wordt bevestigd door http://blogs.technet.com/b/instan/archive/2011/09/27/capi2-event-id-11-retake.aspx, een pagina die veel interessante info bevat over het automatische update proces van root certificaten in Windows Vista en later.

Interessant is dat openen van authroot.stl (vanuit verkenner) geen CAPI2 error logde totdat ik logging van CAPI2 aanzette!

Dat deed ik door (met admin rechten) in event viewer achtereenvolgens te openen: Application and Services Logs, Microsoft, Windows, CAPI2. Daarna rechtsklik op "Operational" en "Enable Log" kiezen (als ik daarna nogmaals rechtsklik op "Operational" zie ik geen vinkje, maar in plaats daarvan "Disable Log"; is dus wel een toggle).

Als ik daarna "authroot.stl" open (door dubbel-klikken in verkenner) leidt dat tot 3 errors in die CAPI2\Operational log, te beginnen met een event ID 11 (dat betreft hier niet een onjuiste datum/tijd issue zoals genoemd in http://support.microsoft.com/kb/2328240, maar "The certificate is not valid for the requested usage").

@Spiff: staat CAPI2 logging aan bij jou? Als ik van een executable de digitale handtekening check leidt dit tot een flink aantal info events onder CAPI2\Operational; bij jou verwacht ik foutmeldingen, wellicht bieden die inzicht wat er misgaat.

Nee, die CAPI2 logging stond nog uit.
Ik wist niet waar dat te vinden en hoe in te schakelen, maar dit was bijzonder nuttig daarbij:
http://blogs.msdn.com/b/benjaminperkins/archive/2013/10/01/enable-capi2-event-logging-to-troubleshoot-pki-and-ssl-certificate-issues.aspx
Update:
Oeps, ik had in je bericht heen gekeken over de uitleg die jij gegeven had over het inschakelen van CAPI2 logging, bóven het @Spiff-stukje:
Hetzelfde als volgens die "Enable CAPI2 event logging" pagina die ik gevonden had. Alsnog bedankt voor die uitleg, ook al had ik er overheen gekeken en de uitleg zelf gezocht. Zelf zoeken is ook altijd waardevol :-)

CAPI2 logging staat nu aan.
Het leidt in enkele seconden tot een enorme rij "Informatie"-logvermeldingen.
Het nu via Windows Explorer bekijken van de details voor de signature van de EMET 4.1 Update 1 installer leidt het tot een logvermelding met onder meer de bekende "De digitale handtekening van het object kan niet worden gecontroleerd" met daarbij nog diverse details.
Hoe trigger ik nu precies een vermelding waaruit ik wijzer kan worden, en belangrijk: welke details moet ik naar op zoek?

Hartelijk bedankt weer voor alle moeite die je neemt en al het meedenken.
Met de CAPI2-logs wil ik later verder.
Nu eerst weer even contact met Microsoft opnemen in verband met dat andere onderwerp:
https://www.security.nl/posting/386491#posting386578

Bedankt allebei. Toch apart dat de eerste TP gewoon vrij beschikbaar is en de 2e verborgen achter een accountsysteem. Bovendien is via Google gewoon helemaal niets te vinden over TP2. Er zullen genoeg mensen zijn die ermee willen stoeien, maar als je niet weet dat het bestaat schiet het ook niet op. Na wat gedoe maar een MS account aangemaakt. Eerst met mailinator adres geprobeerd, maar toen bleef ie eindeloos om extra gegevens vragen, eerst Connect account, dan MS account en zo eindeloos door, ook nog toen ik alle optionele velden had ingevuld :S
Later met nieuw Outlook.com adres wel gelukt.
Ik zie trouwens nergens releas notes/changelog. Hebben jullie die wel gevonden?

Wellicht zou dat Microsoft Connect systeem het voordeel moeten hebben dat de feedback voor iedere deelnemende gebruiker is in te zien en niet alleen voor het EMET Feedback team, vergelijkbaar met het TechNet forum voor EMET, maar nu met feedback betreffend de bèta gescheiden van feedback betreffend de gangbare versie.
En daarnaast is dat Microsoft Connect systeem misschien ook wel bedoeld om een drempeltje op te werpen zodat niet iedereen maar al te gemakkelijk met de bèta's aan de slag gaat en dat bewaard wordt voor wie weet wat daarvan te verwachten?
Maar ik zie dat er binnen Microsoft Connect nog maar pas één feedback-reactie is betreffend EMET 5.0 TP, dus misschien is die drempel van het Microsoft Connect systeem wel te hoog?

Het enige erover dat ik tegengekomen ben, dat is het stukje hierin, maar dat loopt bepaald niet over van informatie over TP2: http://blogs.technet.com/b/srd/archive/2014/04/30/continuing-with-our-community-driven-customer-focused-approach-for-emet.aspx

Hè, vervelend.
Ik had al een Microsoft account, eerder aangemaakt om zo nodig in Microsoft Community en in de TechNet forums te kunnen posten. Het aanmaken daarvan was eerder geen al te grote opgave met een mailinator-adres. Toen ik deze week voor het eerst in tijden dat account weer nodig had, werd me naar aanvullende persoonsgegevens gevraagd. Voor mijn naam heb ik mijn nickname kunnen gebruiken en de rest van de velden heb ik leeg kunnen laten. Voor nieuwe aanmeldingen is het misschien lastiger, zoals uit jouw ervaring lijkt te blijken.

Nee. Ik hoopte die nog binnen het Microsoft Connect EMET 5.0 TP gedeelte te vinden, maar ik heb het er niet kunnen lokaliseren.
Nogal merkwaardig dat release notes of een changelog niet (of zo moeilijk) te vinden zijn. Slordig, zou ik zeggen.

Ik kom nog even terug op het volgens weergave via Windows Verkenner 'niet beschikbare' tijdstip van handtekening van de EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2 bestanden
en de eerder ontbrekende "Microsoft Root Certificate Authority 2010".

Dat eerder ontbrekende "Microsoft Root Certificate Authority 2010" dat blijkt nu inmiddels toch wel degelijk aanwezig te zijn, zoals te zien via certmgr.msc.
Het uitvoeren van KB931125, Update for Root Certificates for Windows Vista, van november 2013, dat heeft blijkbaar dus toch wel degelijk effect gehad, ondanks dat het geen zichtbare bevestiging daarvan te zien gaf. De bevestiging blijkt dus te zien via certmgr.msc, dat laat zien dat "Microsoft Root Certificate Authority 2010" nu aanwezig is.
Dat is tenminste wat :-)

Wat nu echter het raadsel verdiept, dat is dat volgens weergave via Windows Verkenner EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2 nog stééds een 'niet beschikbaar' tijdstip van handtekening hebben!
Dus nog steeds:
Ondanks de nu correct beschikbare "Microsoft Root Certificate Authority 2010" en "Microsoft Root Certificate Authority 2011".

Hoe nu verder te zoeken naar een oorzaak en een oplossing?
De CAPI2-logs?
Het via Windows Explorer bekijken van de details voor de signature van de EMET 4.1 Update 1 of EMET 5.0 Technical Preview 2 installer leidt tot een logvermelding met onder meer de bekende "De digitale handtekening van het object kan niet worden gecontroleerd" met daarbij nog diverse details.
Welke details kunnen relevant zijn? Welke details moet ik naar op zoek?
Of: hoe trigger ik een vermelding waaruit ik wijzer kan worden?

Wie goeie ideeën heeft hierbij - graag!
Leuke puzzel voor het weekend? Tsja, alsof we niks leukers te doen hebben ;-)

Ja dat was mij ook al opgevallen. Ik snap dat ze willen voorkomen dan niet iedereen aan de bèta's gaat, maar vind dit toch overdreven.
Ah dankjewel.

Hè, vervelend.
Ik had al een Microsoft account, eerder aangemaakt om zo nodig in Microsoft Community en in de TechNet forums te kunnen posten. Het aanmaken daarvan was eerder geen al te grote opgave met een mailinator-adres. Toen ik deze week voor het eerst in tijden dat account weer nodig had, werd me naar aanvullende persoonsgegevens gevraagd. Voor mijn naam heb ik mijn nickname kunnen gebruiken en de rest van de velden heb ik leeg kunnen laten. Voor nieuwe aanmeldingen is het misschien lastiger, zoals uit jouw ervaring lijkt te blijken.

Nee. Ik hoopte die nog binnen het Microsoft Connect EMET 5.0 TP gedeelte te vinden, maar ik heb het er niet kunnen lokaliseren.
Nogal merkwaardig dat release notes of een changelog niet (of zo moeilijk) te vinden zijn. Slordig, zou ik zeggen.[/quote]Inderdaad, als testers weten wat er nieuw en/of veranderd is, kan je ook gerichter testen.

@Spiff
De anonieme reactie net is van mij ;)

Opnieuw het register bekeken:
Ondanks dat "Microsoft Root Certificate Authority 2010" nu inmiddels aanwezig is,
ontbreekt nog steeds de betreffende registry key met de SHA1 hash van "Microsoft Root Certificate Authority 2010",
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\
3B1EFD3A66EA28B16697394703A72CA340A05BD5

Wel is er na het uitvoeren van KB931125, Update for Root Certificates for Windows Vista, van november 2013, een hele trits andere vermeldingen bijgekomen, maar merkwaardig genoeg niet die behorend bij "Microsoft Root Certificate Authority 2010".

Kan dat zijn wat er nu de oorzaak van is dat volgens weergave via Windows Verkenner EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2 nog stééds een 'niet beschikbaar' tijdstip van handtekening hebben?

System File Checker (sfc /scannow) levert nog steeds de vermelding:
Er zijn geen schendingen van de integriteit gevonden.

Zoals ik 00:44 uur al zei -
Hoe nu verder te zoeken naar eventueel een oorzaak, maar vooral een praktische en veilige oplossing?

Erik van Straten, Eric-Jan H te A, en Anoniem, heel hartelijk dank voor jullie hulp bij het analyseren en proberen op te lossen van het probleem met de verwerking van certificaten door mijn Vista systeem.

Jammer genoeg hebben we het probleem pas gedeeltelijk weten op te lossen.

Om mijn probleem hopelijk nog breder onder de aandacht te brengen en in de hoop op een oplossing heb ik zojuist een forum-post geplaatst betreffend dat probleem, zie:
https://www.security.nl/posting/386805/Probleem+met+certificaten

Mochten jullie uitgaande van de details zoals ik ze nu op een rij heb gezet nog nieuwe inzichten of suggesties hebben, ik verneem het graag van jullie, en dan wellicht het beste in die forum-thread, als dat jullie ook een goed idee lijkt.

Nogmaals bijzonder hartelijk dank.

Heeft het wel zin om de nieuwe update binnen te halen, ik heb 4.1
Chrome gebruik ik wel, de andere niet.
Ik begrijp dat als ik de update doe, ik eerst 4.1 moet verwijderen, en dan de Update binnen
kan halen. Waarom maakt Microsoft het Updaten van Emet niet eenvoudiger ?
Over de certificaten gaat mijn allemaal boven mijn Pet, ik heb er ook weinig tijd voor.
@Spiff, ik kwam nogal negatieve reacties tegen over jou. Dat vind ik erg laag.....want als er 1 de moeite
neemt om vragen, eenvoudig te beantwoorden ben jij het Spiff, dus Petje af !

Wat bedoel je precies, vanegmond?
Ik heb hier geen negatieve reacties gezien, en dus ook niet over mij.
Bedoel je misschien een heel andere thread?
Een van de weinige threads waar ik volop negatieve reacties kreeg, dat was de "Nutteloze reacties" thread, in 2012. Maar dat was geen normale security-thread, maar een thread die ging over ergernissen en gedrag. Dat wekte een stroom van geërgerde reacties en daarnaast ook wat reacties met herkenning en instemming. Het was een roerige thread :-)
Die thread was toen geplaatst onder het subforum "Algemeen" voor onder meer niet-security topics, later is "Algemeen" merkwaardig genoeg samengevoegd met "Computerbeveiliging".
Maar buiten die thread, weet ik niet waar je het over hebt.

Wat bedoel je precies, vanegmond?
Ik heb hier geen negatieve reacties gezien, en dus ook niet over mij.
Bedoel je misschien een heel andere thread?

Ja in een andere thread Spiff, heb nog gezocht maar kan het niet vinden.
Iemand zei daar `of je niks anders te doen had`
Dat vond ik nogal negatief, vandaar mijn reactie naar jou toe !

Als ik me niet vergis hoef je EMET 4.1 niet te verwijderen voor het installeren van EMET 4.1 update 1.
Dat geldt voor elke EMET update, behalve voor de testversies, als ik me niet vergis.
Een EMET testversie moet wél eerst verwijderd worden voordat een reguliere versie geïnstalleerd wordt.

Nee dat hoeft inderdaad niet, vreemd is wel dat de oude snelkoppelingen verdwijnen.
Wanneer je dan de eerste keer Emet 4.1 Update wil zien, dan gaat die zich eerst installeren en
moet de PC opnieuw worden opgestart.
Dan zijn de oude snelkoppelingen helemaal onbruikbaar.

Op een W 7 32 bits pc hier, ging het helemaal niet. Na updaten is er nm helemaal geen Shortcut meer ?
Er word gemeld Shortcut.GUI.Ink is er niet. Zo is Emet ook niet op te starten !
Dus heb ik de Update verwijderd en 4.0 weer erop gezet.
Op een W 7 64 bits heb ik hetzelfde gedaan en daar geen probleem.

Het lijkt allemaal zo eenvoudig, maar bv met Installeren van de 4.1 Update, kies je voor
Instellingen behouden ? Ik heb gekozen voor Use Recommended Settings, want daarna
via Import, zijn de instellingen snel goed te zetten.

Wilde nog reageren op een XP machine, maar daar ging ineens het Toetsenbord de letters
anders indelen, kwam dit door de site van Security ?
Dus maar niks gedaan verder en op andere sites geen probleem met Toetsenbord !

EMET 4.1V1 crasht zowel Google Chrome en Firefox onder Win7... is dit opzet van MS?