Acceptability Of Self-Sign SSL And Client Certificates

Acceptability Of Self-Sign SSL And Client Certificates

Secure Home | Search | About
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Acceptability Of Self-Sign SSL And Client Certificates Andrew Hayes 06-27-2007
Posted by =?Utf-8?B?QW5kcmV3IEhheWVz?= on June 27, 2007, 9:18 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Normally you would request an SSL certificate from a trusted online root CA,
such as C&W, Verisign, Twawte or any of those listed under Certificates in IE.

As a company specializing in SaaS we have several secure web servers and
intend to add many more, so we would like to be able to issue our own server
certificates for SSL, as well as the client certificates needed to access our
services, and in some cases we digitially sign certain ActiveX components
needed for particular functionality.

What is the general feeling about this in the industry?

Would you, as a prospective customer, think twice about accessing a secure
website where both the server and client certificates were issued by the
company that owns that website?

Or would you think that since you would be signing a contract for services,
including NDA's and SLA's, that you would trust certificates issued by the
company you are contracting with?

Posted by Ray on June 27, 2007, 10:26 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
If these are not publicly accessible servers and the only people you have to
worry about are your customers, how are you going to get your root
certificate on their browsers without causing them a lot of aggravation?

If there is a publicly accessible portal page, what is to prevent me from
creating an identical certificate and spoofing your site?

Personally, I would think you're cheaping out but a lot of other companies
do it. I would definitely use a real code-signing certificate at a minimum.
They are not that expensive.

Ray

> Normally you would request an SSL certificate from a trusted online root
> CA,
> such as C&W, Verisign, Twawte or any of those listed under Certificates in
> IE.
>
> As a company specializing in SaaS we have several secure web servers and
> intend to add many more, so we would like to be able to issue our own
> server
> certificates for SSL, as well as the client certificates needed to access
> our
> services, and in some cases we digitially sign certain ActiveX components
> needed for particular functionality.
>
> What is the general feeling about this in the industry?
>
> Would you, as a prospective customer, think twice about accessing a secure
> website where both the server and client certificates were issued by the
> company that owns that website?
>
> Or would you think that since you would be signing a contract for
> services,
> including NDA's and SLA's, that you would trust certificates issued by the
> company you are contracting with?



Posted by =?Utf-8?B?QW5kcmV3IEhheWVz?= on June 27, 2007, 11:22 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Thanks for the reply Ray. I'll endevour to answer your questions.

> If these are not publicly accessible servers and the only people you have to
> worry about are your customers, how are you going to get your root
> certificate on their browsers without causing them a lot of aggravation?

They have no need of our root certificate. All they get is the publically
available web server certificate. That is, when looking at the HTTPS website
identification they see a certificate like this:

This certificate is intended for the following purpose(s):
Ensures the identity of a remote computer
Issued to: our website
Issued by: our company (rather than Verisign or someone else)
Valid from some-date to some-other-date

Client certificates would be issued using a manual process and not
automatic. Basically, during the initial setup after the customer signs the
contract, we send them the appropriate client certificates for each of their
users. It would cause no more aggravation than if the client certificates
were issued by a "real" CA.

> If there is a publicly accessible portal page, what is to prevent me from
> creating an identical certificate and spoofing your site?

No more than what prevents you from doing the same to Microsoft, Verisign,
or any other Trusted Root CA.

For example.

Type https://download.microsoft.com/ into IE and you'll get a certificate
error. That is because the certificate used to secure the URL was issued to
a248.e.akamai.net by GTE CyberTrust Global Root. No mention of Microsoft even
though it's a Microsoft URL.

For it to work correctly, the certificate would have to be issued to the
exact same URL, and as far as I'm aware there is no way for a URL to resolve
to a different IP address than the one that is in DNS.

If there were, I'm sure http://windowsupdate.microsoft.com/ wouldn't be
pointing at their real website very often.

As with any spoofing or phishing, the weakest link in security is the user.

> Personally, I would think you're cheaping out but a lot of other companies
> do it. I would definitely use a real code-signing certificate at a minimum.
> They are not that expensive.

But I'm not just talking about code-signing. I'm also talking about SSL and
client certificates. We're talking about tens of thousands of certificates.

So what, in your opinion, makes a certificate issed by GoDaddy, Verisign,
Microsoft, C&W, Equifax or Dell, better than one issued by the company that
is providing the service you are paying for?


Posted by Mark Randall on June 28, 2007, 5:33 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> Thanks for the reply Ray. I'll endevour to answer your questions.

> They have no need of our root certificate. All they get is the publically
> available web server certificate. That is, when looking at the HTTPS
> website
> identification they see a certificate like this:

> Client certificates would be issued using a manual process and not
> automatic. Basically, during the initial setup after the customer signs
> the
> contract, we send them the appropriate client certificates for each of
> their
> users. It would cause no more aggravation than if the client certificates
> were issued by a "real" CA.

If it were signed by a 'real' CA then you'd get an automatic certificate
signing chain starting from the root certificates hardcoded into the OS,
that in turn would sign your company certificates and that in turn would
sign your web certs.

> Type https://download.microsoft.com/ into IE and you'll get a certificate
> error. That is because the certificate used to secure the URL was issued
> to
> a248.e.akamai.net by GTE CyberTrust Global Root. No mention of Microsoft
> even
> though it's a Microsoft URL.

Many host names to one IP, the Akamai distribution nodes tend to use actual
DNS redirection if I remember right, but the cert is IP based.

> For it to work correctly, the certificate would have to be issued to the
> exact same URL, and as far as I'm aware there is no way for a URL to
> resolve
> to a different IP address than the one that is in DNS.

Thats easy. Theres nothing in DNS about it being guarenteed correct. Round
Robin DNS redirection works by aiming your dns request at a different IP.
There is nothing to stop a programmer from creating a piece of DNS server
software that replies to one person with one IP, and another person with a
completely different IP for identical requests.

> If there were, I'm sure http://windowsupdate.microsoft.com/ wouldn't be
> pointing at their real website very often.
>
> As with any spoofing or phishing, the weakest link in security is the
> user.
>
>> Personally, I would think you're cheaping out but a lot of other
>> companies
>> do it. I would definitely use a real code-signing certificate at a
>> minimum.
>> They are not that expensive.
>
> But I'm not just talking about code-signing. I'm also talking about SSL
> and
> client certificates. We're talking about tens of thousands of
> certificates.

Hence chaining, you buy your company certificate and then use it to sign
your own.

> So what, in your opinion, makes a certificate issed by GoDaddy, Verisign,
> Microsoft, C&W, Equifax or Dell, better than one issued by the company
> that
> is providing the service you are paying for?
>


Posted by =?Utf-8?B?QW5kcmV3IEhheWVz?= on June 28, 2007, 6:52 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Thanks for the comments Mark. Just one thing I'd like to clarify:

> > But I'm not just talking about code-signing. I'm also talking about SSL
> > and
> > client certificates. We're talking about tens of thousands of
> > certificates.
>
> Hence chaining, you buy your company certificate and then use it to sign
> your own.

Does this mean I can buy 1 company certificate from someone like Verisign
for our CA, and then have all certificates issued by that CA be trusted,
whether it is a web server cert, client cert, or code-sign cert?


Similar ThreadsPosted
VPN Client and Machine Certificates for Unattanded VPN access September 11, 2007, 11:28 am
Certificates March 22, 2007, 12:05 pm
Certificates September 18, 2007, 12:29 am
certificates December 29, 2007, 11:29 pm
Using Certificates for 802.1x and VPN accecss June 29, 2005, 12:25 pm
Re: Expiration Of Certificates July 11, 2005, 8:32 am
What are the differences between the certificates *.pfx *.p12 *.cer *.crt *.spc *.p7b ?? July 19, 2005, 10:02 am
Using Digital Certificates in IIS and .Net October 26, 2005, 4:01 am
How do you get certificates to work February 2, 2006, 3:07 pm
Not Re-issuing certificates May 26, 2006, 4:16 am

The site map in XML format XML site map

Contact Us | Privacy Policy