242040 - Add Unizeto Certum CA certificates to NSS

Status: VERIFIED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Frank Hecker]

Comment 1

[Frank Hecker]

Sorry, accidentally hit return and submitted too soon. To continue...

In accordance with my comments in bug 167572, please add the following
certificates for Unizeto Certum CA (all trust bits on):

Certum Root CA:             http://www.certum.pl/keys/CA.crt
Certum Level I CA:          http://www.certum.pl/keys/level1.crt
Certum Level II CA:         http://www.certum.pl/keys/level2.crt
Certum Level III CA:        http://www.certum.pl/keys/level3.crt
Certum Level IV CA:         http://www.certum.pl/keys/level4.crt
Certum Validation Service:  http://www.certum.pl/keys/vs.crt

(There's also an NSS patch attached to bug 167572, but it doesn't include the
certificate for the Certum Validation Service.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Feank, how many of these certs are root certs?  
It has not been our practice to include intermediate CA certs 
for most CAs.  I think we should NOT include intermediate CA certs
unless there is a good reason to do so.

Comment 3

[Frank Hecker]

(In reply to comment #2)
> Feank, how many of these certs are root certs?  

I think that the cert marked Certum Root CA is the only true root certificate,
but I'd have to double-check that. If everything will work correctly with just
that cert included then go ahead and just include that one. I'll let the folks
from Certum comment on this too. (I'm adding them to the cc list for the bug.) 

Comment 4

[Wojtek Slusarczyk]

The Certum folks are glad to see that including process goes forward. However,
it's a common practice not to add the subordinate CA to a Web server. Thus, we
offen got the following situation: a browser (e.g Microsoft IE with only Certum
CA) is going to establish a secure connection to a server, which has only one
certificate (server ID but not subordinate root CA). In that case, the whole
process gonna finish with "Unable to verify the identity of .... as a trusted
site". We'd like to avoid similar situations in the futre. On the other hand,
you can't validate (by means of OCSP) our IDs without Certum VA, I'm sure. 
So, we appreciate that you are willing to add our CA but please, don't pass 
over subordinate CA's or at least consider it.

Comment 5

[karlsen]

Hi,

IMO there is no need for intermediate CA certs in Mozillas cert store.

SSL/TLS server (including OCSP responder) should be able to send
a complete or almost complete (except the root cert) certificate chain
to the client. SSL/TLS clients should be able to resemble the trustpath
and verify it from a remotely supplied chain together with the local root
certs and any optionally user installed certs. If a server, a client or an
application that want's to be PKIX conform can't do this, I consider them to be
broken in terms of PKIX/X.509 PKI.

Usually Mozilla is working fine in this respect (can't say a thing about
Mozillas OCSP implementation) and admins of IISs need to configure their IIS to
deliver the cert chain, which is possible but not as easy to configure as it is
with Apache webservers. Importing a PKCS12 file into the right Windows
certificate store using the MMC with the certificate snapin does the job.

With IISs out of the box simple standard certificate/request generation
procedure wizard their admins will end up with no chain being delivered. That is
tough. Ask MS to get their IIS cert wizard smarter! Or use proper software.

An example for a kind of broken server is postfix's STARTTLS patch which
can't handle verification of client certificates down to a root cert across
intermediate CA certs.

Cheers

Reimer

Comment 6

[Wojtek Slusarczyk]

(In reply to comment #5)

Hi,

That's true each server shall be able to send a full certificate chain and each
client shall be able to handle a server response. But in fact it's not so easy. 

Mozilla can't handle a OCSP response with VA certificate in it. ISS imports
hardly subordinate CAs into the keystore. Ther's another problem with the IIS -
it requires not only manual inclusion of the intermediate certs in the proper
store, but also requires the user to wait unsepcified time before the IIS 
notices inclusion. 

One of our clients had to wait for several hours before IIS decided to build
complete chain (without any further modification of the stores). It looks like a
"propagation" bug of the changes to cert stores content. Therefore we would like
to secure our clients against such behaviour - and add not only root CA to the
browser keystore, but subordinate certs as well. We also assume, that
intermediate certificates presence both on the server and client side would
render us fewer problems (with not-so-briliant administrators, for example).

regards,
/Wojtek

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Putting on NSS 3.10 radar screen

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch - Add Certum root CA to builtins

This adds the cert with a nickname of "Certum Root CA".

Frank, I think requests for new root CAs like this need to specify two
additional things:
a) the trust flags.  What types of certs is this CA trusted to issue?
   choices include:
	 SSL
	 S/MIME
	 Object Signing
b) what should the nickname of the root CA cert be?

Please let me know if "Certum Root CA" is not desirable.
I used it because it appears in the request (original comment in this 
bug).

NB: I will be on vacation the week of July 18, so I will not reply until
then.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 153451 [details] [diff] [review]
patch - Add Certum root CA to builtins

Julien, please review, then send to wan-Teh for super-review, thanks.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I have made a nssckbi.dll with Certum's root CA added to it. 
I would like someone from Certum to test it for me, and tell me that
they are satisfied that it works OK for them.  If you are that certum 
person, Please email me at the email address given for me in this bug.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This has been checked in on the trunk for NSS 3.10.
So, I am marking this bug fixed.  We may also choose to 
port this enhancement back to NSS 3.9.x.  

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Checked in on the 3.9 branch.
Checking in builtins/certdata.c;   new revision: 1.27.16.1; previous 1.27
Checking in builtins/certdata.txt; new revision: 1.28.16.1; previous 1.28
Checking in builtins/nssckbi.h;    new revision: 1.6.16.2;  previous 1.6.16.1

Comment 13

[Wan-Teh Chang]

Verified with Firefox 1.0.2 that "Certum CA" is in
the "Builtin Object Token" with the following trust
settings:
This certificate can identify web sites.
This certificate can identify mail users.
This certificate can identify software makers.

Its nickname is "Certum Root CA".