Closed Bug 167572 Opened 22 years ago Closed 19 years ago

Add Unizeto CERTUM CA certificates to builtin certificates


(CA Program :: CA Certificate Root Program, task, P3)


(Not tracked)



(Reporter: m.wawoczny, Assigned: hecker)




(Whiteboard: [FIX IN HAND][need a=][need sr=][need r=])


(2 files)

At present day Unizeto CERTUM Certification Authority is managing over 240 000

UNIZETO has its own Certification Authority and is a provider of digital
certificate products, services and solutions that create security, privacy and
authentication in electronic commerce. UNIZETO offers a range of certificate
solutions that encompass Internet security, Extranet security, email security
and Enterprise PKI requirements. UNIZETO wishes to have CERTIFICATES provided as
a part of Mozilla browser and to CERTIFICATES considered as trusted.

This is a blocker for Polish users.
UNIZETO signed email with attached statement regarding non-exclusive license to
manufacture, distribute and sublicense the UNIZETO Root Certificates
Whiteboard: [FIX IN HAND][need a=][need sr=][need r=]
Reassigned to Stephane.
Assignee: wtc → ssaux
Hmmm... Noone can check this patch? 
Is this the correct way to have new Root CA's added to the Mozilla codebase?
I think yes. Patch seems to be OK, the only problem here is $$$ ;) Netscape
support is to expensive, thats why it wasn't checked in.
Enhancement request, requesting addition to built-in root CA shared library.
Waiting OK from assignee.
Severity: major → enhancement
Priority: -- → P3
Marek: How did you make the patch file? I'm trying to make one over in bug 204839
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Is it possible to check in this patch after launch of a new
foundation or Netscape still manages all certificates? 

First of all you need certificate files in binary, der-encoded format (*.crt
files), then you need cert utils (you can build them with NSS).

This is how I generated encoded data for Mozilla:

cat non-repudiation2\ca.crt | addbuiltin -n "Certum CA" -t "C,C,C" > certdata.txt
cat non-repudiation2\level1.crt | addbuiltin -n "Certum Level I" -t "C,C,C" >>
cat non-repudiation2\level2.crt | addbuiltin -n "Certum Level II" -t "C,C,C" >>
cat non-repudiation2\level3.crt | addbuiltin -n "Certum Level III" -t "C,C,C" >>
cat non-repudiation2\level4.crt | addbuiltin -n "Certum Level IV" -t "C,C,C" >>

with -n option you need to specify cert name, and with -t set the certificate
trust attributes:

p valid peer
P trusted peer (implies p)
c valid CA
T trusted CA to issue client certs (implies c)
C trusted CA to issue server certs (implies c)
u user cert
w send warning

/* common defaults */
/* equivalent to "c,c,c" */
void SetValidCA();
/* equivalent to "C,C,C" */
void SetTrustedServerCA();
/* equivalent to "CT,CT,CT" */
void SetTrustedCA();
/* equivalent to "p,," */
void SetValidServerPeer();
/* equivalent to "p,p,p" */
void SetValidPeer();
/* equivalent to "P,P,P" */
void SetTrustedPeer();
/* equivalent to "u,u,u" */
void SetUser();

Flag order: "SSL, Email, ObjSign"

Last step is to add contents of generated certdata.txt to
mozilla/security/nss/lib/ckfw/builtins/certdata.txt file and make a patch.
Depends on: 233453
As with Betrusted (which owns TC TrustCenter, see bug #179716), Unizeto CERTUM
has a WebTrust seal.  
Depends on: 179716
Assignee: ssaux → hecker
Component: Libraries → CA Certificates
Product: NSS →
Version: unspecified → other
Although this bug is related to bug 179716 in the sense that both sets of
certs have the same parent company, neither of these bugs blocks the other.
Both are blocked by bug 233453.
No longer depends on: 179716
Assignee: hecker → hecker
Accepting bug, removing dependency on bug 233453 in accordance with my post to
n.p.m.crypto about proceeding with certain CAs (those with WebTrust CA audits)
in the absence of a full policy.
No longer depends on: 233453
I've put up a web page at

with links to information on this CA; this page is an initial prototype of a
page I hope to create for all the CAs whose certificates are included in Mozilla.

Everything looks OK in terms of having the WebTrust CA audit and the expected
official CA docs (CP, CPS, etc.). I do have one question: As I understand it,
the request is to add certificates for the CERTUM root CA and also for the Level
I through Level 4 CAs under that root. Is this correct?
Yes, you are correct, this bug is to add root CA certificate and beneath it all
level certificates (I to IV). Do I need to change patch file to make this work?
(In reply to comment #15)
> Yes, you are correct, this bug is to add root CA certificate and beneath it
> all level certificates (I to IV). Do I need to change patch file to make this
> work?

I don't think you need to change the patch file at this time. If Nelson Bolyard
(or whoever would make the change) needs a differently-formatted patch file then
they can ask for it. I simply wanted to verify the actual certs to be included,
based on my understanding from reading the patch.

I should have mentioned this in my last comment, but it also appears from
reading the patch that the request is to have all the CA certs trusted for
purposes of SSL, S/MIME email, and object signing -- i.e., all the "trust bits"
turned on for each and every CA. Is this correct?

Yes, all trust bits are enabled, this was requested by Certum CA.
I have now done some additional review on Unizeto Certum CA. I have read the
Certification Policy (CP) and the WebTrust audit report, and skimmed through the
Certification Practice Statement (CPS). I have also successfully imported into
my copy of Mozilla all five CA certificates (root CA and Level I-IV CAs) and
their respective CRLs. Finally, I've successfully surfed to the SSL-enabled
version of the Certum web site <>, which verified properly
(it's got a Level IV certificate). All of this looks OK.

I have a couple of remaining questions about OCSP. (These questions reflect my
relative unfamilarity with OCSP and its implementation in Mozilla; Nelson and
others, please feel free to enlighten me.) As I understand it, Certum maintains
an OCSP responder at the OCSP service URL <>, and responses
are signed using a certificate associated with the Certum Validation Service;
this is presumably the certificate at <>.

My first question is, is it necessary to import this certificate into Mozilla
for Mozilla to properly handle OSCP responses from Certum? And second, what
would I need to do in Mozilla in order to enable checking of Certum certs via
OCSP? Do I simply need to set the option "Use OCSP to validate only certificates
that specify an OCSP service URL"? Or would I have to explicitly specify the
service URL and signer, per the third option "Use OCSP to validate all
certificates using this URL and signer"? Wouldn't the third option apply to
validation of all certificates from any CA, not just Certum? In that case it
would seem that the second option is the one to use, presuming that Certum
actually specifies a service URL in its certs.

I've updated the page at <>
with the URLs for the CRLs and OCSP. If I can get my OCSP-related questions
answered then I am ready to approve addition of the Certum CA certificates per
the interim policy I mentioned above.
I just tested the OCSP capabilities of Mozilla 1.7b against Certum VA. If the
Certum VA certificate is included in Mozilla keystore, it works fine. But if
not, the entire validation proccess is going to fail (error code - unauthorized
response), even though response has a certificate in it. Probably Mozilla
doesn't support that feature correctly. The second OCSP validation method in
Mozilla - trusted VA seems to work fine. But in that case, only IDs issued by
Certum CA will be validated. This is due to a real-time responder, based upon
database not CRLs. So, I guess it would be a great convenience to the Mozilla
users to have a built-in Certum VA (besides Certum {CA,Level{1,2,3,4}}) 

Then, if you wanna use OCSP in Mozilla, you need to

1.get a free ID from :-)
2.set the option "Use OCSP to validate only...."
3.import the Certum VA certificate

That's all.
(In reply to comment #19)
> I just tested the OCSP capabilities of Mozilla 1.7b against Certum VA. If the
> Certum VA certificate is included in Mozilla keystore, it works fine....
> So, I guess it would be a great convenience to the Mozilla
> users to have a built-in Certum VA (besides Certum {CA,Level{1,2,3,4}}) 

Thanks for testing this. I agree that having the CA certificate for the Certum
Validation Service would be useful.

Based on my reading of the Unizeto Certum CA meterials together with comments in
this bug, and in accordance with the interim CA policy outlined
above, I approve including CA certificates for the Unizetum Certum CA,
specifically the Certum Root CA, Certum Level I CA, Certum Level II CA, Certum
Level III CA, Certum Level IV CA, and Certum Validation Service (all
certificates marked as trusted for all uses).

I've submitted a new bug 242040 for the actual addition of the certificates to
NSS, and will mark this bug as blocked pending resolution of bug 242040. If you
have further non-technical comments about this request, please make them in this
bug; please don't comment in bug 242040 unless you are making technical comments
re the requested change to NSS.
Depends on: 242040

Nelson has added these root CA certs to NSS.  So
you can mark this bug fixed now.
Certificates are in Firefox 1.0.2 and Thunderbird 1.0.2; resolving as fixed.
Closed: 19 years ago
Resolution: --- → FIXED
(Forgot to remove bug 242040 as a dependency.)
No longer depends on: 242040
Product: → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.