pki - CRL questions

Designing a basic w2k3 pki for internal purposes. Three tier (root &
intermediate offline, enterprise isuing). Might be expanded to support
external (outside AD forest, outside internal WAN) use in the near future.
Do I need to publish CRL's and AIA to external accessible webservers from
the start, or can I start with internal publishing only?
Can the CRL publishing list be changed for all CAs (external HTTP address
added) without much reconfiguration at a later stage?
What is the preferred order, when using mostly AD integrated clients: ldap
or http first?
I want this design to be flexible, not directly needing an extra layer of
intermediate and issuing CA's when external used certs are needed, but also
want to prevent making irreversible decisions...

Paul
Mon Nov 13 10:35:02 CST 2006

You approach sounds like it may be pretty extreme. You haven't mentioned
why you even want to use PKI. You have decided on the three tier approach,
before you have these other questions answered. I think you might want to
keep an open mind about that part, and design from a services approach
first, then plan your architecture. Making early mistakes with PKI
deployment is expensive.

If you are securing web sites or e-mail that is accessed from the internet,
then you need to make your CRLs accessible from the internet. If you don't
need this now, you probably will in the future. If you ever partner with
other companies, PKI can be a real cost saver. Because of this, you need to
plan early on what URI will be embedded in certificates from the very
beginning.

You sound like you are deploying for a very large organization. You
probably will want to use OCSP (Online certificate status protocol) instead
of CRL. OCSP products from Tumbleweed will give you an amazing amount of
flexibility it this area, and is used by the U.S. military and government.
Microsoft relies on third party solutions for OCSP.

Paul Nelson
Thursby Software Systems, Inc.


in article 9A4A72AB-4203-4555-A81D-D70D22B7B12D@microsoft.com, Ben at
Ben@discussions.microsoft.com wrote on 11/13/06 9:15 AM:

> Designing a basic w2k3 pki for internal purposes. Three tier (root &
> intermediate offline, enterprise isuing). Might be expanded to support
> external (outside AD forest, outside internal WAN) use in the near future.
> Do I need to publish CRL's and AIA to external accessible webservers from
> the start, or can I start with internal publishing only?
> Can the CRL publishing list be changed for all CAs (external HTTP address
> added) without much reconfiguration at a later stage?
> What is the preferred order, when using mostly AD integrated clients: ldap
> or http first?
> I want this design to be flexible, not directly needing an extra layer of
> intermediate and issuing CA's when external used certs are needed, but also
> want to prevent making irreversible decisions...
>

Ben
Tue Nov 14 02:58:01 CST 2006

Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
indeed.
However, we have to do this without third party software (decision alreday
made).

About the services design, you're right, I didn't mention it. I was more
focussed on tech details I guess.
Problem is indeed within the services design: we need to implement -very
fast- a solution to deploy and manage:
- server certificates (DC's: LDAPS, IAS)
- WEBserver: SSL internal only

But at the same time the second demand from management is that the same PKI
infrastructure needs to be ready ('ready' not defined) for (possible)
external use: certificates for VPN connectivity with third parties (b2b), and
perhaps other needs.

So that's where to intermediate CA came in: to be as flexible as possible.
That's also where my question came in: Is it possible to change the CRL
publication list at a later stage, so i'm able to deploy for internal use
right now and modify the list when the demands for external use are clear?





"Paul Nelson" wrote:

> You approach sounds like it may be pretty extreme. You haven't mentioned
> why you even want to use PKI. You have decided on the three tier approach,
> before you have these other questions answered. I think you might want to
> keep an open mind about that part, and design from a services approach
> first, then plan your architecture. Making early mistakes with PKI
> deployment is expensive.
>
> If you are securing web sites or e-mail that is accessed from the internet,
> then you need to make your CRLs accessible from the internet. If you don't
> need this now, you probably will in the future. If you ever partner with
> other companies, PKI can be a real cost saver. Because of this, you need to
> plan early on what URI will be embedded in certificates from the very
> beginning.
>
> You sound like you are deploying for a very large organization. You
> probably will want to use OCSP (Online certificate status protocol) instead
> of CRL. OCSP products from Tumbleweed will give you an amazing amount of
> flexibility it this area, and is used by the U.S. military and government.
> Microsoft relies on third party solutions for OCSP.
>
> Paul Nelson
> Thursby Software Systems, Inc.
>
>
> in article 9A4A72AB-4203-4555-A81D-D70D22B7B12D@microsoft.com, Ben at
> Ben@discussions.microsoft.com wrote on 11/13/06 9:15 AM:
>
> > Designing a basic w2k3 pki for internal purposes. Three tier (root &
> > intermediate offline, enterprise isuing). Might be expanded to support
> > external (outside AD forest, outside internal WAN) use in the near future.
> > Do I need to publish CRL's and AIA to external accessible webservers from
> > the start, or can I start with internal publishing only?
> > Can the CRL publishing list be changed for all CAs (external HTTP address
> > added) without much reconfiguration at a later stage?
> > What is the preferred order, when using mostly AD integrated clients: ldap
> > or http first?
> > I want this design to be flexible, not directly needing an extra layer of
> > intermediate and issuing CA's when external used certs are needed, but also
> > want to prevent making irreversible decisions...
> >
>
>

Brian
Tue Nov 14 03:52:53 CST 2006

In article <3A273915-319B-419E-BFAD-BEA09A1BB9F6@microsoft.com>,
Ben@discussions.microsoft.com says...
> Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
> indeed.
> However, we have to do this without third party software (decision alreday
> made).
>
> About the services design, you're right, I didn't mention it. I was more
> focussed on tech details I guess.
> Problem is indeed within the services design: we need to implement -very
> fast- a solution to deploy and manage:
> - server certificates (DC's: LDAPS, IAS)
> - WEBserver: SSL internal only
>
> But at the same time the second demand from management is that the same PKI
> infrastructure needs to be ready ('ready' not defined) for (possible)
> external use: certificates for VPN connectivity with third parties (b2b), and
> perhaps other needs.
>
> So that's where to intermediate CA came in: to be as flexible as possible.
> That's also where my question came in: Is it possible to change the CRL
> publication list at a later stage, so i'm able to deploy for internal use
> right now and modify the list when the demands for external use are clear?
>
>
>
<SNIP>
You can change the CDP and AIA extension listing at any time, but
remember that this only affects *future* certificates. Existing
certificates will only contain the existing URLs and order of the URLs.
These are not changed as the change would invalidate the signature on
the certificates.

I would recommend establishing the external URL now, or better yet,
establish a URL that is both internally and externally available as the
HTTP URL (pki.company.com). That way you could deploy for now
internally, but when the time comes, publish the URL to the Internet
making it available to external users for certificate validation

Brian

Ben
Tue Nov 14 04:33:02 CST 2006

Brian, thanks for clarifying this matter. I'll probably go with your last
suggestion, thereby preventing from having to renew the intermediate CA cert.

However, this brings up another potential issue: name resolving. Our
environment has different domain naming for external and internal use. When
accessing external names (pki.company.com) this is handled by http proxy
(company.com is not in the proxy exclude list on the clients). There's no
referal (forwarding or root hints) from our internal DNS to the outside
world. We can create an extra zone for company.com on our internal DNS
servers. However, in that case internal PKI clients should resolve this name
to an internal IP address by using these DNS server, not passing the request
to the http proxy server. I'm afraid the PKI enabled apps will use the
default clients proxy settings, thereby delegating the http request to the
proxy server and we'll end up using the DMZ webservers for our internal
clients, which is unwanted (for architectural reasons and because CRL's and
AIA's are not published there yet). Publishing our internal name
(pki.internalname.com) to the internet would be a technical possible
solution, but revealing our internal name structure to the internet is
unwanted either.

So, am I stuck here, is my mind playing tricks with me in the above
reasoning or os there another way out?

BTW: nice coincidence, I was just reading you mspress PKI book. I've read
the wssra en 2003 deployment papers on certificate services, and Jan de
Clercks 2003 security book. However, in my opinion most material isn't very
clear on practical implications of CRL and AIA usage (at least for my
environment). Just arrived at the CRL chapter in your book....

"Brian Komar [MVP]" wrote:

> In article <3A273915-319B-419E-BFAD-BEA09A1BB9F6@microsoft.com>,
> Ben@discussions.microsoft.com says...
> > Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
> > indeed.
> > However, we have to do this without third party software (decision alreday
> > made).
> >
> > About the services design, you're right, I didn't mention it. I was more
> > focussed on tech details I guess.
> > Problem is indeed within the services design: we need to implement -very
> > fast- a solution to deploy and manage:
> > - server certificates (DC's: LDAPS, IAS)
> > - WEBserver: SSL internal only
> >
> > But at the same time the second demand from management is that the same PKI
> > infrastructure needs to be ready ('ready' not defined) for (possible)
> > external use: certificates for VPN connectivity with third parties (b2b), and
> > perhaps other needs.
> >
> > So that's where to intermediate CA came in: to be as flexible as possible.
> > That's also where my question came in: Is it possible to change the CRL
> > publication list at a later stage, so i'm able to deploy for internal use
> > right now and modify the list when the demands for external use are clear?
> >
> >
> >
> <SNIP>
> You can change the CDP and AIA extension listing at any time, but
> remember that this only affects *future* certificates. Existing
> certificates will only contain the existing URLs and order of the URLs.
> These are not changed as the change would invalidate the signature on
> the certificates.
>
> I would recommend establishing the external URL now, or better yet,
> establish a URL that is both internally and externally available as the
> HTTP URL (pki.company.com). That way you could deploy for now
> internally, but when the time comes, publish the URL to the Internet
> making it available to external users for certificate validation
>
> Brian
>

Brian
Tue Nov 14 07:48:11 CST 2006

No real easy answer to this. I typically recommend that you use a URL
that is resolvable both internally and externally. In some cases,
internal clients are directed to a different server (different IP
address returned by the internal DNS infrastructure), and other times,
they connect to the same Web server (potentially in an extranet
location).

Both a good solutions, depends on your requirements.

Brian

In article <67CB4704-9CD4-49BB-80CD-D90911B70FC3@microsoft.com>,
Ben@discussions.microsoft.com says...
> Brian, thanks for clarifying this matter. I'll probably go with your last
> suggestion, thereby preventing from having to renew the intermediate CA cert.
>
> However, this brings up another potential issue: name resolving. Our
> environment has different domain naming for external and internal use. When
> accessing external names (pki.company.com) this is handled by http proxy
> (company.com is not in the proxy exclude list on the clients). There's no
> referal (forwarding or root hints) from our internal DNS to the outside
> world. We can create an extra zone for company.com on our internal DNS
> servers. However, in that case internal PKI clients should resolve this name
> to an internal IP address by using these DNS server, not passing the request
> to the http proxy server. I'm afraid the PKI enabled apps will use the
> default clients proxy settings, thereby delegating the http request to the
> proxy server and we'll end up using the DMZ webservers for our internal
> clients, which is unwanted (for architectural reasons and because CRL's and
> AIA's are not published there yet). Publishing our internal name
> (pki.internalname.com) to the internet would be a technical possible
> solution, but revealing our internal name structure to the internet is
> unwanted either.
>
> So, am I stuck here, is my mind playing tricks with me in the above
> reasoning or os there another way out?
>
> BTW: nice coincidence, I was just reading you mspress PKI book. I've read
> the wssra en 2003 deployment papers on certificate services, and Jan de
> Clercks 2003 security book. However, in my opinion most material isn't very
> clear on practical implications of CRL and AIA usage (at least for my
> environment). Just arrived at the CRL chapter in your book....
>
> "Brian Komar [MVP]" wrote:
>
> > In article <3A273915-319B-419E-BFAD-BEA09A1BB9F6@microsoft.com>,
> > Ben@discussions.microsoft.com says...
> > > Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
> > > indeed.
> > > However, we have to do this without third party software (decision alreday
> > > made).
> > >
> > > About the services design, you're right, I didn't mention it. I was more
> > > focussed on tech details I guess.
> > > Problem is indeed within the services design: we need to implement -very
> > > fast- a solution to deploy and manage:
> > > - server certificates (DC's: LDAPS, IAS)
> > > - WEBserver: SSL internal only
> > >
> > > But at the same time the second demand from management is that the same PKI
> > > infrastructure needs to be ready ('ready' not defined) for (possible)
> > > external use: certificates for VPN connectivity with third parties (b2b), and
> > > perhaps other needs.
> > >

Ben
Tue Nov 14 08:57:01 CST 2006

I'll try to get some more advise on DNS naming constructs. Paul is plain
right advising OCSP. CRL/AIA publishing and ordering is just not flexibile
enough.
Will Longhorn pki support OCSP?


"Brian Komar [MVP]" wrote:

> No real easy answer to this. I typically recommend that you use a URL
> that is resolvable both internally and externally. In some cases,
> internal clients are directed to a different server (different IP
> address returned by the internal DNS infrastructure), and other times,
> they connect to the same Web server (potentially in an extranet
> location).
>
> Both a good solutions, depends on your requirements.
>
> Brian
>
> In article <67CB4704-9CD4-49BB-80CD-D90911B70FC3@microsoft.com>,
> Ben@discussions.microsoft.com says...
> > Brian, thanks for clarifying this matter. I'll probably go with your last
> > suggestion, thereby preventing from having to renew the intermediate CA cert.
> >
> > However, this brings up another potential issue: name resolving. Our
> > environment has different domain naming for external and internal use. When
> > accessing external names (pki.company.com) this is handled by http proxy
> > (company.com is not in the proxy exclude list on the clients). There's no
> > referal (forwarding or root hints) from our internal DNS to the outside
> > world. We can create an extra zone for company.com on our internal DNS
> > servers. However, in that case internal PKI clients should resolve this name
> > to an internal IP address by using these DNS server, not passing the request
> > to the http proxy server. I'm afraid the PKI enabled apps will use the
> > default clients proxy settings, thereby delegating the http request to the
> > proxy server and we'll end up using the DMZ webservers for our internal
> > clients, which is unwanted (for architectural reasons and because CRL's and
> > AIA's are not published there yet). Publishing our internal name
> > (pki.internalname.com) to the internet would be a technical possible
> > solution, but revealing our internal name structure to the internet is
> > unwanted either.
> >
> > So, am I stuck here, is my mind playing tricks with me in the above
> > reasoning or os there another way out?
> >
> > BTW: nice coincidence, I was just reading you mspress PKI book. I've read
> > the wssra en 2003 deployment papers on certificate services, and Jan de
> > Clercks 2003 security book. However, in my opinion most material isn't very
> > clear on practical implications of CRL and AIA usage (at least for my
> > environment). Just arrived at the CRL chapter in your book....
> >
> > "Brian Komar [MVP]" wrote:
> >
> > > In article <3A273915-319B-419E-BFAD-BEA09A1BB9F6@microsoft.com>,
> > > Ben@discussions.microsoft.com says...
> > > > Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
> > > > indeed.
> > > > However, we have to do this without third party software (decision alreday
> > > > made).
> > > >
> > > > About the services design, you're right, I didn't mention it. I was more
> > > > focussed on tech details I guess.
> > > > Problem is indeed within the services design: we need to implement -very
> > > > fast- a solution to deploy and manage:
> > > > - server certificates (DC's: LDAPS, IAS)
> > > > - WEBserver: SSL internal only
> > > >
> > > > But at the same time the second demand from management is that the same PKI
> > > > infrastructure needs to be ready ('ready' not defined) for (possible)
> > > > external use: certificates for VPN connectivity with third parties (b2b), and
> > > > perhaps other needs.
> > > >
>

Brian
Tue Nov 14 09:06:07 CST 2006

In article <F4F576D3-00DB-4AB9-9A6E-A40465535A3D@microsoft.com>,
Ben@discussions.microsoft.com says...
> try to get some more advise on DNS naming constructs. Paul is plain
> right advising OCSP. CRL/AIA publishing and ordering is just not flexibile
> enough.
> Will Longhorn pki support OCSP?
>
>
Yes. Longhorn will include an OCSP server and Windows Vista ships with
an OCSP client built in. No need for third party.
But... You will still have a similar issue in your case for the URL for
the OCSP responder...
Brian

Ben
Tue Nov 14 09:22:01 CST 2006



"Brian Komar [MVP]" wrote:

> In article <F4F576D3-00DB-4AB9-9A6E-A40465535A3D@microsoft.com>,
> Ben@discussions.microsoft.com says...
> > try to get some more advise on DNS naming constructs. Paul is plain
> > right advising OCSP. CRL/AIA publishing and ordering is just not flexibile
> > enough.
> > Will Longhorn pki support OCSP?
> >
> >
> Yes. Longhorn will include an OCSP server and Windows Vista ships with
> an OCSP client built in. No need for third party.
> But... You will still have a similar issue in your case for the URL for
> the OCSP responder...
> Brian
>
aahrggggg... would farming or selling used cars be an option for me? :-(
Thanks Brian, thanks Paul for your the great support. I'll do some more
research and perhaps get back. BTW: great group, good response. Thanks again!

Martin
Thu Nov 16 03:41:40 CST 2006

I have a similar question,

Suppose I have root CA which issuses certificates to CA for intranet and
another CA for extranet.

Is it possible to divide root CDPs for intranet (also include LDAP for
example) and CDP for extranet (HTTP only)?

I could change the CDP before issuing the extranet CA certificate and
then change it back but I suppose there are couple of issues connected
with this workaround.

First of all I would probably need to change the CDP every time I issue
a CRL, so the Published CRL Locations URL is correctly filled.

Are there any other issues?

Would it be better to use one CDP (e.g. extranet site accessible from
extranet and intranet) and do not include LDAP CDP for offline root ca?

Thanks in advance.

Martin


Brian Komar [MVP] wrote:
> No real easy answer to this. I typically recommend that you use a URL
> that is resolvable both internally and externally. In some cases,
> internal clients are directed to a different server (different IP
> address returned by the internal DNS infrastructure), and other times,
> they connect to the same Web server (potentially in an extranet
> location).
>
> Both a good solutions, depends on your requirements.
>
> Brian
>
> In article <67CB4704-9CD4-49BB-80CD-D90911B70FC3@microsoft.com>,
> Ben@discussions.microsoft.com says...
>> Brian, thanks for clarifying this matter. I'll probably go with your last
>> suggestion, thereby preventing from having to renew the intermediate CA cert.
>>
>> However, this brings up another potential issue: name resolving. Our
>> environment has different domain naming for external and internal use. When
>> accessing external names (pki.company.com) this is handled by http proxy
>> (company.com is not in the proxy exclude list on the clients). There's no
>> referal (forwarding or root hints) from our internal DNS to the outside
>> world. We can create an extra zone for company.com on our internal DNS
>> servers. However, in that case internal PKI clients should resolve this name
>> to an internal IP address by using these DNS server, not passing the request
>> to the http proxy server. I'm afraid the PKI enabled apps will use the
>> default clients proxy settings, thereby delegating the http request to the
>> proxy server and we'll end up using the DMZ webservers for our internal
>> clients, which is unwanted (for architectural reasons and because CRL's and
>> AIA's are not published there yet). Publishing our internal name
>> (pki.internalname.com) to the internet would be a technical possible
>> solution, but revealing our internal name structure to the internet is
>> unwanted either.
>>
>> So, am I stuck here, is my mind playing tricks with me in the above
>> reasoning or os there another way out?
>>
>> BTW: nice coincidence, I was just reading you mspress PKI book. I've read
>> the wssra en 2003 deployment papers on certificate services, and Jan de
>> Clercks 2003 security book. However, in my opinion most material isn't very
>> clear on practical implications of CRL and AIA usage (at least for my
>> environment). Just arrived at the CRL chapter in your book....
>>
>> "Brian Komar [MVP]" wrote:
>>
>>> In article <3A273915-319B-419E-BFAD-BEA09A1BB9F6@microsoft.com>,
>>> Ben@discussions.microsoft.com says...
>>>> Thanks for suggesting Tumbleweed. Seems like a pack of flexible solutions
>>>> indeed.
>>>> However, we have to do this without third party software (decision alreday
>>>> made).
>>>>
>>>> About the services design, you're right, I didn't mention it. I was more
>>>> focussed on tech details I guess.
>>>> Problem is indeed within the services design: we need to implement -very
>>>> fast- a solution to deploy and manage:
>>>> - server certificates (DC's: LDAPS, IAS)
>>>> - WEBserver: SSL internal only
>>>>
>>>> But at the same time the second demand from management is that the same PKI
>>>> infrastructure needs to be ready ('ready' not defined) for (possible)
>>>> external use: certificates for VPN connectivity with third parties (b2b), and
>>>> perhaps other needs.
>>>>