|
Posted by Brian Komar on April 30, 2007, 10:56 pm
Please log in for more thread options OK, we are getting closer.
This could be due to permissions on the CDP and AIA locations.
What I recommend is that you take the certificate you are trying to add
from the directory.
At the computer you are trying to add the certificate, do the following
command
certutil -verify -urlfetch otherpersonscert.crt
This will perform the validation in your security context and will attempt
to download all certs and CRLs from the referenced URLs.
Another possibility is that a user has an older certificate from when
things were not correctly configured published to the userCertificate
attribute.
CRL checking *is* performed when you add a new user to the EFS file. CRL
checking is *not* performed when you actually perform encryption. The only
check done is that the EFS certificate is still time valid.
Brian
On Tue, 1 May 2007 07:01:48 +0530, camexan wrote:
> Brian,
>
> first thanks for reply. Pkiview.msc shows everything OK. I verified the
> following:
>
>
> - CRLs are published by CAs to the CDP locations (this is OK)
> - Clients obtain EFS certificates from EntIssuing CA (this is OK)
> - Encryption of file with EFS certificate user obtained from
> EntIssuing CA now works (this is OK)
> - Addition of another user certificate issued by EntIssuing CA
> doesn't work – EFSADU „revocation server offline“ message (this is
> NOT OK)
>
>
> I checked cache locations on client computer and found out that there's
> no CRL files at all. My reasoning is that clients cannot download CRLs –
> although all permissions for CDPs and CDP extensions field in
> certificates are configured right.
>
> I cannot find source of the problem: why clients cannot obtain CRLs.
> Furthermore, EFSADU „revocation server offline“ message is thrown right
> away after I click on OK button to add user – as if contacting CDPs
> isn't done at all(?). Could this be problem with EFSADU... (?)
>
> How to find a cause clients cannot retrieve CRL ... (although
> everything seems to be configured right).
>
> Camil.
>
>
> Brian Komar;2811447 Wrote:
>> First thing that I would do is validate the CDP and AIA extensions.
>> Run pkiview.msc (from the resource kit tools) and verify that *all* CDP
>> and
>> AIA points are considered Valid (expiring is OK too).
>>
>> Brian
>>
>> On Sun, 29 Apr 2007 23:35:24 +0530, camexan wrote:
>>
>>> Hello to all!!!
>>>
>>> I had installed EntRoot and EntIssuing CAs for my test environment
>>> (they are both online), and after that configured them like this:
>>>
>>> EntRoot
>>> - CDP and AIA locations left on default.
>>> - Base CRL publication is 1 week, no Delta CRLs.
>>> - Deleteted all cert tmpls from CA>Certificate Templates except
>>> Subordinate Certification Authority.
>>>
>>>
>>> EntIssuing
>>> - CDP and AIA locations left on default
>>> - Base CRL publication is 1 Days, Delta CRL publication is 6 hours,
>> and
>>> AD replication is 2 hours (as this is my test environment)
>>> - Created new FirmaEFS cert tmpl upon the Basic EFS, on its
>>> Properties>Superceded Templates tab add Basic EFS, and after that
>>> deleted Basic EFS from CA>Certificate Templates.
>>>
>>> Trouble is: I obtained some certificates based upon the FirmaEFS
>> cert
>>> tmpl on my client computer for two different users, by using
>>> Certificates snap-in console. However, when I try to use them for
>>> encryption of files I get some errors:
>>> - When I try to encrypt files, a new local certificate is
>> self-issued
>>> to the user and used for encryption (that is not part of the CA
>>> hierarchy), and not that obtained for EntIssuing CA. Is it possible
>> to
>>> force user cert obtained from EntIssuing CA to be used for
>> encryption
>>> (i.e. to manually select certificate that will be used)?
>>> - When I try to add certificate of users issued by EntIssuing CA, on
>>> the Encryption Details dialog of the file, I receive „revocation
>> server
>>> offline“ error. Then I manually checked that CDP and AIA locations
>> are
>>> available, and they are, but it seems that clients cannot access
>> them.
>>> How can I troubleshoot whether clients have the access to the CRLs?
>>> - Furthermore, in Certificates snap-in console on client, in
>>> Intermediate Certification Authority>Certificate Revocation List
>> node,
>>> there's no EntIssuing CRL. I imported it manually, restarted the
>>> client, but I have the same error symptoms as previously. How can I
>> see
>>> that client is consulting this CRL for revocation, and does it use
>> some
>>> other ones from its cached locations?
>>>
>>> I would appreciate if you can help me with this!
>>>
>>> Camil.
|