|
Posted by Joe Kaplan on July 20, 2007, 11:49 am
Please log in for more thread options
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
--
> 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
| 
XML Sitemap