Re: Newbie wants to learn about PKI Server 2003......



In article <eT1yqAPkGHA.1600@xxxxxxxxxxxxxxxxxxxx>, in the
microsoft.public.windows.server.security news group, Joe <jwdaigle@xxxxxxxxxxxxx> says...

<snip>

I have read stuff on Technet, bought Brian Komar's excellent "Windows Server
2003 PKI Certificate Security", and have been lurking here for a bit.

Brian is my business partner, I'll pass along your kind words.


Is there anything else I can read/do to educate myself on PKI as implemented
in Server 2003?

http://www.microsoft.com/pki, though from the sounds of it you've probably already discovered
this resource.

<snip>


Proposed design:
We will implement a 2 tier heirarchy, with the Root CA being offline. There
will be 1 Issuing CA running Enterprise. We will publish our CRLs & Certs
on an external HTTP URL, and use AD to distribute CRLs & Certs internally.

Sounds good.


Questions (feel free to point me somewhere for more information):
- CDPs are really confusing to me. Simple concept until you get down to
implementing them.
- since we want them to be accessible outside our firewall, we cant just
specify LDAP in our lists, right?

Correct, unless you were also publishing an LDAP server externally, which you can do with
AD/AM for example but this is probably overly complex for your environment.

But on the other hand, we want our
internal users to have fast access to them.
- I am thinking about specifying the external HTTP URL first (to
accomodate external users), and relying only on AD for the internal users.

All clients that attempt revocation checking will first attempt to retrieve the CRL from the
external web site. There is no concept of internal versus external users here. Issued
certificates will contain an ordered list of CDP locations and the client side code will
attempt to retrieve the CRLs from the CDP locations based on this order. Your internal
clients will only retrieve the CRL from Active Directory if they are unable to access the
external web site. Also, if they are unable to access the external web site, there will be a
noticeable delay in their applications while the attempt to retrieve the CRL times out. Note
that there is nothing inherently wrong with your internal users retrieving the CRL from an
external web site and publishing to AD is still a good idea as it provides for redundancy for
your internal users.

Do I need to specify anything in the CDP for internal users, or is it
"automatic" once I -dspublish the Root CA?

Ok, so now you're a little confused. As above, the CDP is "baked" into the certificate and is
determined by and configured on the CA that issues the certificate. Also as above, there is
no way to specify one CDP for internal users and a different one for external users. Finally,
publishing the root CA certificate to AD has nothing to do with CDPs, it simply makes
deployment of the root CA cert to your internal clients easier as it will be pushed out via
Group Policy.

- The default CDP/AIA has like 4 locations. localfilesystem, LDAP, HTTP
& another I dont remember. Are all of these required? If I dont specify
the localfilesystem, will all my internal users be checking them on the
external HTTP URL?

You must keep the local file system location as that will allow you to copy the CRLs to your
web site. No one actually checks the copy of CRL that is published to the CA's local file
system. You can verify this by looking at the check boxes for this CRL location. The location
is specifically not included in issued certificates.

- When building the Root CA, I took the recommendation from the book about
leaving the CDP & AIA blank in the CAPolicy.inf file. Is that a best
practice (maybe a stupid question cuz its out of a book, but I have been
burned by that assumption before :-))?

Yes, this is both a best practice and follows the rules in RFC3280. You need to think of a
CRL as a signed "document" if you will. The CRL is signed by the CA that issues it. In the
case of a root CA, you're dealing with a self-signed certificate. If you were to revoke the
root CA certificate, the CRL that contained this revocation would then have to be signed with
a revoked certificate, which really doesn't make much sense. Also, according to RFC3280,
applications that perform CRL checking are supposed to stop checking revocation status one
level below a self-signed cert, so applications that are 3280 compliant would never check the
revocation status of a root cert.

What actually does that mean? Does
it mean that there is no revocation checking for the Root CA,

Yes, as above.

or does it
mean I cant revoke the SubCA that the Root CA will sign?

No, you can still revoke SubCA certs. If you were to specify a CDP URL in CAPolicy.inf for
the root CA, it would only ever appear in the root CA cert. The CDP that would potentially
contain a revoked SubCA certificate is configured in the registry of the root CA and is done
after the root CA is installed but before it issues any certificates and is contained in the
certificates issued by the root CA.

- It appears that I can change the AIA & CDP paths any time I want. If I
change them, the only effect this has is for future issued Certs for that
CA, right?

Correct.

- Once a Root CA is -dspublish'd, how do I "get rid of it"? There doesnt
seem to be a -dsrevoke.

You need to delete it from AD. You can do this with Active Directory Sites and Services or
with the PKIView tool from the resource kit. Note that deleting the cert from AD will not
remove it from clients.

- This brings up the question of what scope a CRL has. Is it only the
parent CA that can revoke a SubCAs Cert? or can a CA revoke its own Cert?

Only the CA that issues a cert can revoke the cert.


Sorry so long, but I was hoping someone could skim through what I have said
here and tell me if I am headed in the right direction. Thanks!

Hope this helps.

--
Paul Adare - MVP Virtual Machines
http://www.identit.ca
It all began with Adam. He was the first man to tell
a joke--or a lie. How lucky Adam was. He knew when he
said a good thing, nobody had said it before. Adam was
not alone in the Garden of Eden, however, and does not
deserve all the credit; much is due to Eve, the first
woman, and Satan, the first consultant." - Mark Twain
.



Relevant Pages

  • Re: ADFS Token-signing Certs Not in Trusted Root Store
    ... This is good info, Joe. ... So now I know that the token-signing certificate is ... Get a signing cert from a CA ... case, you never have to worry about expiration or CRL checking, as your cert ...
    (microsoft.public.windows.server.active_directory)
  • "include in CDP" extention error - Reproducible error:
    ... Cert Auth Properties, that I have to re-issue the CAExch cert because PKIView ... users where to get CRL and CA cert files. ... Wrong Issuer "Certificate " Time: ...
    (microsoft.public.security)
  • Re: Thawte Digital Certificate Revocation List Issue
    ... > I am new to digital certificates and cannot get the Thawte certificate ... It's been awhile since I played with the Thawte certificates. ... Microsoft requires the cert ... CRL so Outlook doesn't know where to get ...
    (microsoft.public.security)
  • Help PKI installation - lots of questions !
    ... One STAND ALONE ROOT CA called SACAMX00 (SA stand for Stand Alone, ... AMERICAS Sub & CA ASIA Sub ... Client use this to find Delta CRL ... publish my CRL again even if no certificate are revoked? ...
    (microsoft.public.security)
  • Re: Help PKI installation - lots of questions !
    ... One STAND ALONE ROOT CA called SACAMX00 (SA stand for Stand Alone, ... AMERICAS Sub & CA ASIA Sub ... Client use this to find Delta CRL ... publish my CRL again even if no certificate are revoked? ...
    (microsoft.public.security)