Kontrollerar Internet Explorer spärrstatus på klientcertifikat?

Att Net iD inte gör (och inte heller bör göra) spärrkontroll av certifikaten på korten vet vi. Att domänkontrollanterna kontrollerar spärrstatus på det certifikat man loggar med vet vi också.

AD_logon_with_revoked

Att IIS också gör det är även det känt.

IIS_standard_revocation_message

Synd bara att IIS ger samma felmeddelande för a) Certifikatent är spärrat och b) Kunde inte hämta spärrinformation

Men hur är det med Internet Explorer?

Ja, Internet Explorer kollar spärrstatus på två sätt:

1) Spärrstatus för servercertifikat på https-siter som besöks

There are a policy settings allowing you to manage whether Internet Explorer will check revocation status of servers’ certificates. Certificates are revoked when they have been compromised or are no longer valid, and this option protects users from submitting confidential data to a site that may be fraudulent or not secure.

ie_gpo_server

server_cert_001

Denna artikel kommer inte att behandla området servercertifikat mer än att konstatera det ovan beskrivna.

2) Spärrstatus för klientcertifikat som t.ex. kan användas för klientautentiserad SSL (dubbelriktad SSL)

Det finns en inställning i Internet Explorer men den verkar inte påverka det test som beskrivs nedan. Vi får återkomma till vad den egentligen gör.

ie_gpo_unclear

Testet

Här en bild på en användares certifikatslager: (inkopierade från kortet av Net iDs certifikatkopieringsfunktion, iid.exe)

card_with_revoked_certificates

Alla dessa certifikat är revokerade utom certifikatet högst upp (SecMaker CA v2). Här en kontroll av certifikat nummer 7 i listan:

revoked_certificate

Dåså, låt oss tömma den lokala CRL-cachen och använda kortet och ett av de spärrade certifikaten. Här visas cachen, helt tom som synes.

local_crl_cache_001

Därefter kör vi inloggning mot en site som litar på certifikat utfärdade av SecMaker CA v2 och SITHS CA v3. Dvs. innan Windows på eget bevåg laddat hem och cachat spärrinformationen.

Vi borde alltså kunna se fyra, av de sju certifikaten i Mystore, i valdialogen. Jajjamensann, det gör vi:

IE_without_cached_CRL

Därefter gör vi om samma inloggningsförsök men nu med SITHS CRL:en cachad lokalt. Den andra posten är den som är aktuell för vårt test:

local_crl_cache_002

Om allt nu stämmer borde Internet Explorer filtrera bort de tre spärrade certifikaten utgivna av SITHS CA v3 och bara visa ett. Jo, det stämmer fint:

IE_with_cached_CRL

Denna filterfunktion i Internet Explorer verkar endast fungera då IE (version 8 i detta test) körs under Windows 7. Vårt test på Windows XP IE visades även de spärrade certifikaten trots att den lokala cachen innehöll SITHS CRL.

Disk and Memory Caches

CryptoAPI uses the following two caches for CRLs and OCSP responses:
A disk cache, which maintains copies of all CRLs and OCSP responses retrieved during the revocation checking process on the local file system. All items in the disk cache are maintained until their validity period expires.

A memory cache, which contains revocation information used by a specific process. The memory cache is maintained within the memory used by the calling process. When the process terminates, the memory is released and the memory cache is flushed. If an object exists in the disk cache, the object is read into the memory cache for the calling process.

Table 1 provides details on the disk cache locations for computers running Windows Vista and Windows Server 2008, or Windows XP and Windows Server 2003 operating systems.

Location Windows XP and Windows Server 2003 Windows Vista and
Windows Server 2008
Per User C:\Documents and Settings\username\Application Data
\Microsoft\CryptnetUrlCache
C:\Users\username\AppData\LocalLow
\Microsoft\CryptnetUrlCache
Per Computer C:\Windows\System32\config\systemprofile
\Application Data\Microsoft\CryptnetUrlCache
C:\Windows\System32\config\systemprofile
\AppData\LocalLow\Microsoft\
CryptnetUrlCache

Inspect the chache

Use thos command to inpect the cache

certutil -urlcache CRL

local_crl_cache_003

Verbose for ”CRL” doesn’t work

certutil -urlcache CRL –v

But without the ”CRL” or ”URL” argument we can have it in verbose mode

local_crl_cache_004

Or redirect the whole thing to a file

certutil -urlcache -v >CRL-rapport.txt

Flushing the Disk Cache

For Windows XP or Windows Server 2003, it is now supported to delete items from the disk cache. There are different commands available for flushing the cache:

To delete the CRL cache:

certutil -urlcache crl delete
To delete the OCSP cache:

certutil -urlcache ocsp delete
To delete all cache entries:

certutil -urlcache * delete
It may be necessary to restart the application or even the computer in order to flush the CRL cache in Windows XP or Windows Server 2003.

To use Certutil.exe on a Windows XP client, you must install the Windows Server 2003 Administration Tools Pack. Certutil.exe works in the user context in which it is called. The commands here would delete the cache for the currently logged in user. To delete the cache for other users, the command would need to be run in corresponding user context.

Flushing the Memory Cache

For Windows Vista and Windows 2008, it is preferable to invalidate the memory cache instead of deleting the disk cache. You can do so by invalidating the cached CRLs and OCSP responses before the time specified in the object. To invalidate the cache, you must run the following commands from an Administrative command prompt:

To immediately invalidate all items from the cache:

certutil -setreg chain\ChainCacheResyncFiletime @now
To invalidate the currently cached items in 1 day, 2 hours:

certutil -setreg chain\ChainCacheResyncFiletime @now+1:2
To identify the last time that the cache was invalidated:

certutil -getreg chain\ChainCacheResyncFiletime
If the ChainCacheResyncFiletime was never manually set, the registry key will not exist and the getreg command will fail. This is expected behavior. This registry key is applied for the whole computer, so the commands here will invalidate the cache for all processes running on the computer. To reset the ChainCacheResyncFileTime, set it to a time sufficiently in the past using the setreg command.