Prev: Made a big mistake - VPN and RPC over HTTP (SBS 2003 Prem.)
Next: The received certificate has expired
From: Ace Fekay [MCT] on 4 Jan 2010 18:51
"Mike W." <MikeW(a)discussions.microsoft.com> wrote in message
news:1454EE81-FD55-4AB2-BB26-2FF2413D54BF(a)microsoft.com...
>
>
> "Ace Fekay [MCT]" wrote:
>
>> The private key belongs to GoDaddy, and they hold it, hence why it's not
>> exportable, because it's not part of the cert.
>
> Ok. But then I'm confused as to why the Help File within SBS asks the user
> to export the certificate with the private key. When would that be
> possible
> if the cert creator holds the key?
>
>


True, however you stated in another post that you were able to export it?

Ace


From: Cliff Galiher on 4 Jan 2010 22:53
Ace,

That isn't exactly accurate. Every *server* certificate in IIS has to have
a private key. The public key is sent when a request from a browser hits
IIS...that is the certificate you see and can view in the address bar. The
public key is used to *decrypt* data. The private key is used to *encrypt*
data. IF IIS didn't have a private key for the certificate then IIS would
have no way to properly encrypt the data. If the public key was used to
encrypt the data then anybody with a browser who could view and save your
certificate would then be able to encrypt the data (as that is the public
key) and then be able to pose as you. So a private key is, indeed, on the
IIS server for *any* server certificate, GoDaddy or otherwise. And if it is
in the certificate store, then it is exportable. Hence, see my previous
post that the problem he saw with the certificate *not* being exportable was
a sign that that the private key had been deleted/lost/removed and thus that
was why the problem existed.

....to be fair, (cuz I know an uber-nerd will call me out on it) the
certificates are not used for encryption. They are only used to *negotiate*
the encryption. But the methodology is still the same. The only way to
validate that the certificate sent to a browser is valid is if a private key
does exist on IIS. No private key in IIS then no validation. So as long as
the cert is valid, it has an exportable key.

....now, what you say is *also* true, but at a different level. GoDaddy (and
every 3rd-party certificate vendor for that matter) has a private key that
you *don't* have access to. That private key is used to "sign" your
certificate. That is, in fact, the differentiator between a self-signed
certificate and a 3rd-party certificate. If you had GoDaddy's private key
then you could sign certificates as them all day long...even for malicious
sites. Not very secure and would make 3rd-party providers not at all
trusted (or trustable if such a word exists.) But their private key is NOT
directly associated with your certificate. It is only used in generating
the certificate to provide validity that they vouch for you. You still have
your own private key that is generated when you create the CSR.

....so that is why a GoDaddy certificate *should* be able to be exported
*with* a private key, if the certificate is indeed a valid server
certificate and has been properly installed in the certificate store.

Hope that clears some things up, as I see that there was some confusion.

-Cliff


"Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
news:eOL6vNXjKHA.1824(a)TK2MSFTNGP04.phx.gbl...
> "Mike W." <MikeW(a)discussions.microsoft.com> wrote in message
> news:48842970-D7FB-4626-B776-B3B2BE846832(a)microsoft.com...
>>
>>
>> "Bill Sanderson" wrote:
>>
>>> In my case, I simply read and followed the instructions in the install
>>> certificate wizard. I was able to export the in-place (godaddy)
>>> certificate
>>> with no issues, but that wasn't needed--I proceeded through the wizard,
>>> told
>>> it to use the existing certificate, which it did without complaint.
>>
>> I read an blog post that referenced the GoDaddy certs and how exporting
>> the
>> in-place cert would work. However, the step-by-step that I had found
>> indicated I need to export the private key. That option wasn't available
>> to
>> me. I am unsure why.
>>
>> Thanks for this follow-up. It's also curious that you ran into the same
>> troubles...
>
>
> The private key belongs to GoDaddy, and they hold it, hence why it's not
> exportable, because it's not part of the cert.
>
> Ace
>
From: Ace Fekay [MCT] on 5 Jan 2010 01:24
"Cliff Galiher" <cgaliher(a)gmail.com> wrote in message
news:uP2H1qbjKHA.2132(a)TK2MSFTNGP05.phx.gbl...
> Ace,
>
> That isn't exactly accurate. Every *server* certificate in IIS has to
> have a private key. The public key is sent when a request from a browser
> hits IIS...that is the certificate you see and can view in the address
> bar. The public key is used to *decrypt* data. The private key is used
> to *encrypt* data. IF IIS didn't have a private key for the certificate
> then IIS would have no way to properly encrypt the data. If the public
> key was used to encrypt the data then anybody with a browser who could
> view and save your certificate would then be able to encrypt the data (as
> that is the public key) and then be able to pose as you. So a private key
> is, indeed, on the IIS server for *any* server certificate, GoDaddy or
> otherwise. And if it is in the certificate store, then it is exportable.

You know, I thought about that after I posted, regarding the single key
encryption, hence what SSL uses, and the private key has to exist locally
for it to work. Thanks for bringing my memory back. :-)

> Hence, see my previous post that the problem he saw with the certificate
> *not* being exportable was a sign that that the private key had been
> deleted/lost/removed and thus that was why the problem existed.

So when he deleted the CSR, it removed the private key that was generated
(the thumbprint) that was used to purchase/acquire the cert, hence why he
couldn't import the cert.

> ...to be fair, (cuz I know an uber-nerd will call me out on it) the
> certificates are not used for encryption. They are only used to
> *negotiate* the encryption.

You're right, it is not specifically used to encrypt, rather to instantiate
encryption where the browser generates a session key to be used for
encryption. Breaking it down, during browser-server negotiation, The server
responds sending the website's cert, along with the server�s SSL version
number, cipher settings, etc. The browser validates the cert checking the
expiration date, site name match, and if the CA's public key is in the
browser which then the CA's pub key in the browser checks the server's
digital signature to make sure it is accurate. Once that is done, then the
browser generates a unique �session key� that will be used to encrypt
communications using asymmetric encryption. The browser then encrypts the
session key itself with the website�s public key, then sends it to the
server. The webserver then decrypts the session key with its own private
key.

It's also interesting that many understand SSL encryption is symmetric
encryption (single key), but the least understood part (more like never
clearly explained) is that a private-public key pair (assymetric) is used
during negotiation to generate the session key.

> But the methodology is still the same. The only way to validate that the
> certificate sent to a browser is valid is if a private key does exist on
> IIS. No private key in IIS then no validation. So as long as the cert is
> valid, it has an exportable key.

Good point. :-)

>
> ...now, what you say is *also* true, but at a different level. GoDaddy
> (and every 3rd-party certificate vendor for that matter) has a private key
> that you *don't* have access to. That private key is used to "sign" your
> certificate. That is, in fact, the differentiator between a self-signed
> certificate and a 3rd-party certificate. If you had GoDaddy's private key
> then you could sign certificates as them all day long...even for malicious
> sites. Not very secure and would make 3rd-party providers not at all
> trusted (or trustable if such a word exists.) But their private key is
> NOT directly associated with your certificate. It is only used in
> generating the certificate to provide validity that they vouch for you.
> You still have your own private key that is generated when you create the
> CSR.
>
> ...so that is why a GoDaddy certificate *should* be able to be exported
> *with* a private key, if the certificate is indeed a valid server
> certificate and has been properly installed in the certificate store.

I've never used GoDaddy certs. I've heard there are nuances and loopholes
(is that a good word for it?) that I don't agree with, such as what you've
described. I purchase my certs and my customer certs from DigiCert. They are
their own CA, and not chained, such as InstantSSL. They are less expensive
than the other CAs, too. They even have a wizard to help generate a UC/San
cert CSR that you can use with Exchange 2007 and 2010.

The FBI and US Dept of Justice uses them

>
> Hope that clears some things up, as I see that there was some confusion.
>
> -Cliff

Yes, thanks.

A little tidbit of info about coming back from memory when I used to teach
Security courses years ago. The private and public keys are mathematically
related. The key pairs are actually generated is based on very large Prime
Numbers.

The private key is two randomly selected extremely large prime numbers.
However with specific public CAs, I believe they add their own identifiers
(MIB??) as part of the primes picked. For example, the following are two
very large primes:

846254449268
6863898952

They are multiplied to give the Public Key: 1683233547460440441497

That's why it's extremely difficult (I'm not going to use the word
"impossible") to break the public key to figure out it's private key. No
known mathematical formula has been discovered that can quickly factor two
Prime numbers from one large one.

And GoDaddy gives their private key away!

Anyway, thanks again, Cliff!

Ace






From: Domquark on 16 Jan 2010 17:14
This issue appears to only happen on SBS - NOT a "full" Server 2008/Exchange
2007 combination. I have upgraded a number of Server/Exchange systems, with
no issues. But SBS has caused untold grief including a nasty habit of
completely disabling the SBS website, knocking out Exchange, OWA, RWW etc.
This requires modification of IIS settings to get everything back - in
addition to creating the certificate headache.

My advice is don't apply Exchange SP2 to SBS2008!
(Until there is a specific SBS version, at least)


"Mike W." wrote:

> Here's an update for everyone:
>
> The answer to this was to perform as re-key, as Susan and Cliff both
> mentioned. I created a new CSR via the SBS2008 wizard, sent that to my
> provider, then got a new key quickly. I installed it this morning and
> everything is fine.
>
> My colleague and I talked. He's much more cautious than I am and was
> surprised by this outcome. Nevertheless, I am sure we're going to be updating
> other Exchange 2007 servers to sp2 (no other SBS2008 systems, mind you) so I
> have some experience in case something like this happens again. At the best,
> I will export the in-use cert's private key before updating. At the worst,
> I'll do another re-key.
>
> Thanks everyone!
>
> Cheers,
>
> Mike...
From: Domquark on 17 Jan 2010 15:11
If it's of help to people -

If you have NOT generated a new CSR, but installing Ex2007 SP2 has knocked
out IIS, Exchange etc. (and your certificate does not appear in the wizard)
then the answer is to manually install your certificate. This has to be done
onto the Sharepoint and Web Applications sites in IIS. If you run the
Get-ExchangeCertificate you may find that Exchange has no services assigned
to it. Reassign services (POP, SMTP, IMAP and IIS) onto Exchange via your
certificate's thumbprint and all is well again.

"Domquark" wrote:

> This issue appears to only happen on SBS - NOT a "full" Server 2008/Exchange
> 2007 combination. I have upgraded a number of Server/Exchange systems, with
> no issues. But SBS has caused untold grief including a nasty habit of
> completely disabling the SBS website, knocking out Exchange, OWA, RWW etc.
> This requires modification of IIS settings to get everything back - in
> addition to creating the certificate headache.
>
> My advice is don't apply Exchange SP2 to SBS2008!
> (Until there is a specific SBS version, at least)
>
>
> "Mike W." wrote:
>
> > Here's an update for everyone:
> >
> > The answer to this was to perform as re-key, as Susan and Cliff both
> > mentioned. I created a new CSR via the SBS2008 wizard, sent that to my
> > provider, then got a new key quickly. I installed it this morning and
> > everything is fine.
> >
> > My colleague and I talked. He's much more cautious than I am and was
> > surprised by this outcome. Nevertheless, I am sure we're going to be updating
> > other Exchange 2007 servers to sp2 (no other SBS2008 systems, mind you) so I
> > have some experience in case something like this happens again. At the best,
> > I will export the in-use cert's private key before updating. At the worst,
> > I'll do another re-key.
> >
> > Thanks everyone!
> >
> > Cheers,
> >
> > Mike...
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Made a big mistake - VPN and RPC over HTTP (SBS 2003 Prem.)
Next: The received certificate has expired