Unfortunately this does not work.
Example: Yes, when i give it a few Days, the client will retrieve the
actual crl faster. But the auth still works.
I have tried it. I revoked an cert. Installed a new win10 client and
joined the domain. After login with the revoked p12 cert on a yubikey, i
can see he queries the CDP and still allows the login.
With certutil and a cert in DER format, i tried this:
certutil -f -urlfetch -verify testus-cert.cer
The output says that the cert is revoked. But login was granted. That is
completly strange.
Someone an Idea?
Am 19.07.2023 um 14:08 schrieb Andrey Repin via samba:> Hello Hans Schulze,
>
> Wednesday, July 19, 2023, 1:03:25 PM, you wrote:
>
>> Thanky you, for the Info.
>> After some research, here is some further information:
>> The current stable kerberos implementation make no crl verify. At this
time
>> only the domain member like win10 clients make these. After joining the
>> domain and first login with smartcard, they try to resolve the CRL
>> Distribution Points for all certs of the chain. Only one url that
cannot be
>> reached and the authentication fails.
>> The funny thing is, they are retrieved
>> and cached only once, as long as the validity of the crl is given.
Should a
>> new crl be issued, the clients would still have the old crl cached.
Thats a problem.
> You should not issue CRL with very long validity period.
> Give it a few days over your routine CRL update cycle and it should work.
>
>> This mechanics was implemented to reduce the traffic to the
distribution point.
>> You can check the cache with certutil on windows client, like:
>> certutil ?urlcache CRL
>> These are my thoughts on this and I hope someone else can use them to
>> better understand similar problems. I think this mechanic is a little
>> security issue. But we hope that the new version will be released soon
and will fix this problem.
>