Re: Using Self-Issued Certificate in lieu of 3rd Party Certificate
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 20 Jul 2007 10:49:17 -0500
Regarding the 128 bit vs 1024 bit thing, what they are likely talking about
is that the symmetric cipher they use is 128 bit strength (probably RC2
which is pretty common). SSL always uses a combination of certificate-based
asymmetric encryption with symmetric encryption. The symmetric encryption
encrypts the actual stream of data, whereas the asymmetric encryption is
used to negotiate the session key that will be used for the symmetric
encryption. 128 bit is probably fine for symmetric encryption.
I would be shocked if someone was actually recommending using a cert with a
128 bit RSA key. That isn't really done.
Regarding the CA approach for the site, it really depends on who will be
accessing the site. If the public will be accessing the site, then you
really want to use a certificate that chains to a publicly trusted root.
Otherwise, normal browsers will not trust it and they'll get a warning.
This is the primary reason why people buy certs from public providers.
Their CA cert will chain to a standard publicly trusted root.
If you can control all of the machines that will be accessing the site and
can install your root CA cert in their trusted roots cert store, then it is
feasible to issue the certificate from your own CA as trust can be
established that way.
Actual self-signed certs really have no place outside of test labs. By
default, no one trusts them, so they are very hard to make work in any kind
of deployment scenario.
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
--
"Scott" <Scott@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:DB005E5A-7C6F-4B48-A96B-9072BA77E8B4@xxxxxxxxxxxxxxxx
We are working with an application vendor in SSL security for a Web-facing
server in the DMZ which is also an Active Directory member. I created an
Active Directory Enterprise CA and then a subordinate CA for the server
with
1024 bit security with RSA and SHA1.
The vendor is now coming in at the 11th hour and providing documentation
indicating that they support SSL v2, v3 and TLS v1 and only
fully-authenticated 128 bit SSL certificates. Their non-technical
employees
are trying to steer us to 3rd parties like Verisign, Thawte or GeoTrust
and
away from self-issued certificates. I am trying to get in touch with an
SSL-knowledgeable tech at the vendor.
I'm obviously concerned about 128 bit since it is so easily cracked these
days with only the processing power of a recent vintage PC. Setting that
issue aside though, how can I dumb down my self-issued certificate so that
it
meets the vendor's requirement? Their server has a 'MakeCSR' utility to
create and encrypt a private key. They are saying that a 3rd party vendor
will ask for the CSR generated by their utility as part of the process of
issuing their certificate.
Does my AD Enterprise CA or server subordinate CA have the ability to
interoperate with this application vendor in a way which could satisfy
their
requirements? If so, how? Can the already issued certificates be modified
to
satisfy the requirements or would they be deleted and new ones be created?
Scott
.
- Prev by Date: Re: Adding multiple entries for the same user with xcacls...
- Next by Date: Logon/Logoff Events in Local Security Log of Terminal Server
- Previous by thread: Adding multiple entries for the same user with xcacls...
- Next by thread: Logon/Logoff Events in Local Security Log of Terminal Server
- Index(es):
Relevant Pages
|
