Problems enabling SSL on AD

Hi,

We've been trying to enable SSL on our AD system. We followed procedure at:

http://support.microsoft.com/kb/321051

Prior to doing anything, we imported the CA and SubCA certs on the AD
machine using the MMC Certificates snap-in.

Then, we created the cert request using certreq, submitted the request
to the SubCA, and saved the server cert that the SubCA issued.

We got an error (don't remember what) when we tried to do the "certreq -
accept", so then we used the MMC Certificate snap-in to import the
server cert into Local Computer/Personal.

We restarted the AD machine, but even after that, when we test SSL using
ldp.exe, we cannot connect.

When we double-click on the server cert in MMC Certificate snap-in on
the AD machine, the server cert looks ok, so I'm puzzled by why the SSL
is still not working.

I did note that when we double-click on the cert, the text "You have a
private key that corresponds to this certificate" is *NOT* displayed,
and I also note that in the article above, one of the requirements is:

"A private key that matches the certificate is present in the Local
Computer's store and is correctly associated with the certificate.
The private key must not have strong private key protection
enabled."

So, I'm thinking that the problem is that we don't have the private key
associated with the server cert, but I don't know why not?

I thought that when we created the cert request using the certreq.exe,
that that would cause a private key to be created and stored, but we
must be doing something wrong.

Can anyone here tell me what step we missed and how we create/store the
private key that that article is talking about?

Thanks in advance,
Jim

Something got hosed between the request for the certificate and the actual
receipt of it. You probably have the private key on your machine somewhere
(since you requested the certificate based on a key pair you generated), but
somehow when the cert from the CA came back, it didn't get properly
associated with the original request, so Windows doesn't know that the cert
you have belongs to the private key.

If you don't have the private key, you can't do SSL, so the cert is
basically useless.

I'd suggest asking what to do over on ms.public.platformsdk.security to see
if there is a way to recover from this situation. Ideally, there is some
way you can get the issued certificate associated with the private key you
already have and then you are fine. That would be better than starting
over. However, starting over and trying again might be easier.

Having a p12 or pfx file for the cert is always the most flexible option, as
you can then install it anywhere you like. The private key and cert travel
together. However, they are also the most dangerous thing from a security
perspective for exactly the same reason that they are the most convenient.
Security is always like that. :)

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"ohaya" <ohaya@cox.net> wrote in message
news:e3q89AQPHHA.4260@TK2MSFTNGP02.phx.gbl...
> Hi,
>
> We've been trying to enable SSL on our AD system. We followed procedure
> at:
>
> http://support.microsoft.com/kb/321051
>
> Prior to doing anything, we imported the CA and SubCA certs on the AD
> machine using the MMC Certificates snap-in.
>
> Then, we created the cert request using certreq, submitted the request to
> the SubCA, and saved the server cert that the SubCA issued.
>
> We got an error (don't remember what) when we tried to do the "certreq -
> accept", so then we used the MMC Certificate snap-in to import the server
> cert into Local Computer/Personal.
>
> We restarted the AD machine, but even after that, when we test SSL using
> ldp.exe, we cannot connect.
>
> When we double-click on the server cert in MMC Certificate snap-in on the
> AD machine, the server cert looks ok, so I'm puzzled by why the SSL is
> still not working.
>
> I did note that when we double-click on the cert, the text "You have a
> private key that corresponds to this certificate" is *NOT* displayed, and
> I also note that in the article above, one of the requirements is:
>
> "A private key that matches the certificate is present in the Local
> Computer's store and is correctly associated with the certificate.
> The private key must not have strong private key protection
> enabled."
>
> So, I'm thinking that the problem is that we don't have the private key
> associated with the server cert, but I don't know why not?
>
> I thought that when we created the cert request using the certreq.exe,
> that that would cause a private key to be created and stored, but we must
> be doing something wrong.
>
> Can anyone here tell me what step we missed and how we create/store the
> private key that that article is talking about?
>
> Thanks in advance,
> Jim

Joe,

Thanks for the detailed response...

I tried the same procedure per the MS KB article here last night, on a
test system that I have, and it worked. But, note by "per the MS KB
article", I used the "certreq -accept", and that worked here, whereas we
had a problem with the "certreq -accept" in the earlier try, which was
in our lab. We eventually were able to import the cert into the Local
Computer\Personal store by using MMC Certificates snap-in.

Question: Does "certreq -accept" do something different than using the
MMC Certificates snap-in to import the server cert? In particular, I'm
wondering if using the MMC Certificates snap-in to do the import doesn't
do the association between the private key and the server cert,
whereas using "certreq -accept" does some extra stuff to do the association?

Jim



Joe Kaplan wrote:
> Something got hosed between the request for the certificate and the actual
> receipt of it. You probably have the private key on your machine somewhere
> (since you requested the certificate based on a key pair you generated), but
> somehow when the cert from the CA came back, it didn't get properly
> associated with the original request, so Windows doesn't know that the cert
> you have belongs to the private key.
>
> If you don't have the private key, you can't do SSL, so the cert is
> basically useless.
>
> I'd suggest asking what to do over on ms.public.platformsdk.security to see
> if there is a way to recover from this situation. Ideally, there is some
> way you can get the issued certificate associated with the private key you
> already have and then you are fine. That would be better than starting
> over. However, starting over and trying again might be easier.
>
> Having a p12 or pfx file for the cert is always the most flexible option, as
> you can then install it anywhere you like. The private key and cert travel
> together. However, they are also the most dangerous thing from a security
> perspective for exactly the same reason that they are the most convenient.
> Security is always like that. :)
>
> Joe K.
>

Joe,

I think that I was just able to replicate the problem that we
encountered earlier. Here's what I did:

1) I did the "certreq -new...".

2) In MMC Certificates snap-in, I deleted the entry under Local
Computer\Certificate Enrollment Requests

3) I submitted the cert request to the CA, and got the new cert.

4) When I tried to run "certreq -accept...", I got a popup error,
"Cannot find object or property. 0x80092004." When I clicked the OK
button, the following was output:

"Certificate Request Processor: Cannot find object or property.
0x80092004..."

5) I used the MMC Certificates snap-in to try to import the server cert
into the Local Computer\Personal store (this is what I did in the lab
after someone else reported that the "certreq -accept..." had failed).
This worked.

6) When I look at the server cert in the MMC Certificates snap-in, the
"You have a private key..." text does not appear.


I'm not exactly sure how this would have occurred, but I think that
someone else had tried some stuff before I got there, so I think that,
by the time I got to our lab, the Local Computer\Certificate Enrollment
Requests store may have already been mucked up, when I tried to do this.

I've found that if I clean out the Local Computer\Personal store and the
Local Computer\Certificate Enrollment Requests store, and then REBOOT
THE AD machine, and then go through the procedure in the MS KB article,
that works successfully.

From what I can tell, after you remove the server cert, you HAVE TO
bounce the AD machine, otherwise, AD seems to still think it has the
server cert.

On the other hand, when you ADD the server cert, this seems to take
effect immediately, i.e., AD SSL is enabled immediately without a reboot.

Thanks for ALL of your help! You may not know it, but some of your
explanation, e.g., about certreq and associating the private key and the
server cert, was very helpful in my trying to replicate this problem :)!!!!

Jim



ohaya wrote:
> Joe,
>
> Thanks for the detailed response...
>
> I tried the same procedure per the MS KB article here last night, on a
> test system that I have, and it worked. But, note by "per the MS KB
> article", I used the "certreq -accept", and that worked here, whereas we
> had a problem with the "certreq -accept" in the earlier try, which was
> in our lab. We eventually were able to import the cert into the Local
> Computer\Personal store by using MMC Certificates snap-in.
>
> Question: Does "certreq -accept" do something different than using the
> MMC Certificates snap-in to import the server cert? In particular, I'm
> wondering if using the MMC Certificates snap-in to do the import doesn't
> do the association between the private key and the server cert, whereas
> using "certreq -accept" does some extra stuff to do the association?
>
> Jim
>
>
>
> Joe Kaplan wrote:
>> Something got hosed between the request for the certificate and the
>> actual receipt of it. You probably have the private key on your
>> machine somewhere (since you requested the certificate based on a key
>> pair you generated), but somehow when the cert from the CA came back,
>> it didn't get properly associated with the original request, so
>> Windows doesn't know that the cert you have belongs to the private key.
>>
>> If you don't have the private key, you can't do SSL, so the cert is
>> basically useless.
>>
>> I'd suggest asking what to do over on ms.public.platformsdk.security
>> to see if there is a way to recover from this situation. Ideally,
>> there is some way you can get the issued certificate associated with
>> the private key you already have and then you are fine. That would be
>> better than starting over. However, starting over and trying again
>> might be easier.
>>
>> Having a p12 or pfx file for the cert is always the most flexible
>> option, as you can then install it anywhere you like. The private key
>> and cert travel together. However, they are also the most dangerous
>> thing from a security perspective for exactly the same reason that
>> they are the most convenient. Security is always like that. :)
>>
>> Joe K.
>>

Excellent, that's great. I know some stuff about PKI and AD, but I'm not
super deep in this area. I'm glad that was adequate. I learned a bunch
from your response as well, so thanks!

In any event, someone in one of the crypto-focused newsgroups could have
certainly picked it up from there.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"ohaya" <ohaya@cox.net> wrote in message
news:%23xEKYSaPHHA.3544@TK2MSFTNGP03.phx.gbl...
> Joe,
>
> I think that I was just able to replicate the problem that we encountered
> earlier. Here's what I did:
>
> 1) I did the "certreq -new...".
>
> 2) In MMC Certificates snap-in, I deleted the entry under Local
> Computer\Certificate Enrollment Requests
>
> 3) I submitted the cert request to the CA, and got the new cert.
>
> 4) When I tried to run "certreq -accept...", I got a popup error, "Cannot
> find object or property. 0x80092004." When I clicked the OK button, the
> following was output:
>
> "Certificate Request Processor: Cannot find object or property.
> 0x80092004..."
>
> 5) I used the MMC Certificates snap-in to try to import the server cert
> into the Local Computer\Personal store (this is what I did in the lab
> after someone else reported that the "certreq -accept..." had failed).
> This worked.
>
> 6) When I look at the server cert in the MMC Certificates snap-in, the
> "You have a private key..." text does not appear.
>
>
> I'm not exactly sure how this would have occurred, but I think that
> someone else had tried some stuff before I got there, so I think that, by
> the time I got to our lab, the Local Computer\Certificate Enrollment
> Requests store may have already been mucked up, when I tried to do this.
>
> I've found that if I clean out the Local Computer\Personal store and the
> Local Computer\Certificate Enrollment Requests store, and then REBOOT THE
> AD machine, and then go through the procedure in the MS KB article, that
> works successfully.
>
> From what I can tell, after you remove the server cert, you HAVE TO bounce
> the AD machine, otherwise, AD seems to still think it has the server cert.
>
> On the other hand, when you ADD the server cert, this seems to take effect
> immediately, i.e., AD SSL is enabled immediately without a reboot.
>
> Thanks for ALL of your help! You may not know it, but some of your
> explanation, e.g., about certreq and associating the private key and the
> server cert, was very helpful in my trying to replicate this problem
> :)!!!!
>
> Jim
>
>
>
> ohaya wrote:
>> Joe,
>>
>> Thanks for the detailed response...
>>
>> I tried the same procedure per the MS KB article here last night, on a
>> test system that I have, and it worked. But, note by "per the MS KB
>> article", I used the "certreq -accept", and that worked here, whereas we
>> had a problem with the "certreq -accept" in the earlier try, which was in
>> our lab. We eventually were able to import the cert into the Local
>> Computer\Personal store by using MMC Certificates snap-in.
>>
>> Question: Does "certreq -accept" do something different than using the
>> MMC Certificates snap-in to import the server cert? In particular, I'm
>> wondering if using the MMC Certificates snap-in to do the import doesn't
>> do the association between the private key and the server cert, whereas
>> using "certreq -accept" does some extra stuff to do the association?
>>
>> Jim
>>
>>
>>
>> Joe Kaplan wrote:
>>> Something got hosed between the request for the certificate and the
>>> actual receipt of it. You probably have the private key on your machine
>>> somewhere (since you requested the certificate based on a key pair you
>>> generated), but somehow when the cert from the CA came back, it didn't
>>> get properly associated with the original request, so Windows doesn't
>>> know that the cert you have belongs to the private key.
>>>
>>> If you don't have the private key, you can't do SSL, so the cert is
>>> basically useless.
>>>
>>> I'd suggest asking what to do over on ms.public.platformsdk.security to
>>> see if there is a way to recover from this situation. Ideally, there is
>>> some way you can get the issued certificate associated with the private
>>> key you already have and then you are fine. That would be better than
>>> starting over. However, starting over and trying again might be easier.
>>>
>>> Having a p12 or pfx file for the cert is always the most flexible
>>> option, as you can then install it anywhere you like. The private key
>>> and cert travel together. However, they are also the most dangerous
>>> thing from a security perspective for exactly the same reason that they
>>> are the most convenient. Security is always like that. :)
>>>
>>> Joe K.
>>>

Joe,

Just to close this thread off, one of our guys just went onsite, and did
the procedure, this time cleaning out the Local Computer\Certificate
Enrollment Requests and Local Computer\Personal stores before starting,
and everything worked... and got AD SSL-enabled!!

Cool :)!

Again, thanks for all of your help, and methinks you are being WAY too
modest :)!!

Jim



Joe Kaplan wrote:
> Excellent, that's great. I know some stuff about PKI and AD, but I'm not
> super deep in this area. I'm glad that was adequate. I learned a bunch
> from your response as well, so thanks!
>
> In any event, someone in one of the crypto-focused newsgroups could have
> certainly picked it up from there.
>
> Joe K.
>