Hi!
On Sun, 19 May 2002, Pidgorny, Slav wrote:
> 2. I sent this request as a request for a Web server SSL certificate.
> 3. The Verisign test CA did not complain upon processing this request. It
> generated and signed the certificate.
I think this is normal behaviour. You submitted a valid request and a valid cert
came out. That's the purpose of a test CA ...
> 4. I installed the certificate to MS Certificate Services and start the CA
> service.
> 5. From now on, I effectively have a signed CA certification. Any generated
> signatures from this point will have a certification path leading to the
> root CA.
The Verisign test CA's root certificate is not installed in IE/Windows by
default. I don't see how can there be a valid certification path to a root CA
in your case ... Only those entities are going to accept certificates signed by
your CA, which have the Verisign test CA's certificate in their local
repository.
> I only used Verisign test root CA in my test.
If you install the Verisign test CA's certificate as a root certificate in your
application, then it's your responsibility, and you alone have to face the
consequences. Nobody else will accept certificates issued by your CA, because
nobody else trusts the test CA of Verisign and any certificates issued by it ...
> The steps above can probably be repeated using Verisign production root CA,
> resulting the situation whereas I'm becoming a subordinate CA to Verisign
> trusted root without letting them know.
There's only one way to get your CSR signed by Verisign's production root CA:
you have to pay for it. If you misleadingly tell them that you're going to use
the certificte for server-side SSL only (you request a certificate for a
webserver), and afterwards you use the matching private key to sign documents,
then you will be violating your contract with Verisign. It's up to you ...
If they find out they will most likely revoke your certificate. If they don't
find out that means you use the certificate for signature only internally ...
and nobody cares whether you do or not ...
> Do you think it's a security problem?
Not really. OK. Maybe a little bit.
Some technical background info ...
X.509 v3 type of certificates may contain so called "standard extensions" which
are also covered by the issuer's siganture, and therefore should be handled as
trustworthy information. These extensions are structured in the following way:
- extension type
- value
- criticality flag (boolean)
When the criticality flag is set, it indicates that the certificate processing
application shall not ignore the given extension in any situation, and that the
certificate must be refused if the extension cannot be interpreted by the
application.
Most well known root certificates do have standard extensions. They incorporate
mainly the following information:
- Basic Constraints: Subject Type=CA, Path Length Constraint=n
(where "n" used to be between 3 and 8)
- Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing
Some root certificates contain these with the criticality bit set, and some
without it.
Webserver SSL certificates signed by Verisign contain these extensions (and
some others as well):
- Basic Constraints: Subject Type=End Entity, Path Length Constraint=None
- Enhanced Key Usage: ? (IE could not interpret this field)
You can see that the subject is to be an "End Entity", and not a CA. But ...
None of these extensions are set as critical! So the MS certificate server might
accept a Verisign production webserver certificate as a CA certificate to no
shame. It's the application's right to decide what to do with non-critical
extensions.
However, as I already said ... you are not supposed to use the certificate for
anything else than server-side SSL encryption.
It seems to me that most certificates contain "Subject Type" as a non-critical
extension. I think this might be considered a security issue ...
Basically any private key and its matching certificate can be used for signing
purposes ... Applications handle standard extensions in various ways, so you
cannot say that incorporating the Subject Type as critical extension will keep
anybody from using a webserver certificate to sign documents, etc.
/*
Just for the record ...
In IE the certificates have an "Enhanced key usage" property, which describes
the intended usage of the given certificate and its matching private key.
However, this cannot be trusted as it's only a "property" and therefore is not
covered by the signature of the certificate's issuer. The "properties" of a
certificate can be editied by any entity ... The same information might be
incorporated in standard extensions, so I don't see any sense in using these
"properties" at all ... Anybody got an idea on this?
*/
PS: I mentioned IE as a reference for a certificate processing application,
because probably it's the most widespread X.509 certificate handling
application on Earth ... unfortunately.
--
Muller Zsolt / student (Computer Science)
email: mulzs@inf.bme.hu, mulzs@freemail.hu
WWW: http://www.inf.bme.hu/~mulzs/
