Add TURKTRUST root CA certificates to NSS

RESOLVED FIXED in 3.11.9

Status

enhancement
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: hecker, Assigned: kaie)

Tracking

unspecified
3.11.9
All
macOS
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

This bug requests inclusion in the NSS root certificate store of the following
two root CA certificates, owned by TÜRKTRUST:

1) Friendly name: "TURKTRUST Certificate Services Provider Root 1"
   SHA-1 fingerprint:
79:98:A3:08:E1:4D:65:85:E6:C2:1E:15:3A:71:9F:BA:5A:D3:4A:D9
   Trust flags: Email, Object signing
   URL:
http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt

2) Friendly name: "TURKTRUST Certificate Services Provider Root 2"
   SHA1 Fingerprint:
B4:35:D4:E1:11:9D:1C:66:90:A7:49:EB:B3:94:BD:63:7B:A7:82:B7
   Trust flags: Web sites, Email, Object signing
   URL:
http://www.turktrust.com.tr/sertifikalar/kok_s2.crt

The certificate(s) themselves will be attached momentarily, as downloaded from
the URLs above and verified using the stated fingerprints. Note that I contacted TÜRKTRUST via telephone and confirmed that the above SHA-1 fingerprints are correct for the certificates to be included. I will also send a signed email to the bug assignee confirming the fingerprints.

The TÜRKTRUST CA has been assessed in accordance with the Mozilla project
guidelines, and the certificates approved for inclusion per bug 380635.

The remaining steps are as follows:

1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate(s) have been attached.

2) The Mozilla representative adds the certificate(s) to the store, and marks the bug RESOLVED FIXED.

3) When a development version of Firefox becomes available with the certs included, a representative of the CA must download a copy and confirm (by adding a comment here) that the certificates have been correctly imported. If this does not happen, the certificates will be removed again.

4) The bug is VERIFIED.
SHA-1 fingerprint:
79:98:A3:08:E1:4D:65:85:E6:C2:1E:15:3A:71:9F:BA:5A:D3:4A:D9
SHA1 Fingerprint:
B4:35:D4:E1:11:9D:1C:66:90:A7:49:EB:B3:94:BD:63:7B:A7:82:B7
Assignee: nobody → kengert
> 1) A representative of the CA must confirm that all the data in this bug is
> correct, and that the correct certificate(s) have been attached.

Dear Turktrust representatives, can you please confirm this?
Blocks: 411299
My apologies, the procedure I outlined above is incorrect; thanks to Kai for pointing me to the correct procedures.

The steps are as follows:

1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate(s) have been attached. They must also specify what OS they would like to use to perform the verification below.

2) A Mozilla representative creates a test build of NSS with the new certificate(s), and attaches nssckbi.dll to this bug. A representative of the CA must download this, drop it into a copy of Firefox and/or Thunderbird on the OS in question and confirm (by adding a comment here) that the certificate(s) have been correctly imported and that websites work correctly.

3) The Mozilla representative checks the certificate(s) into the NSS store, and marks the bug RESOLVED FIXED.

4) At some time after that, various Mozilla products will move to using a version of NSS which contains the certificate(s). This process is mostly under the control of the release drivers for those products.
cc-ing Mert Özarar of TÜRKTRUST on this bug. Mr Özarar, please see my comment #4 above. 
Please note that I plan to produce a single version of the nssckbi (module with roots) only, for Windows. I hope you will be able to do all your testing on Windows. This will save me from doing extra work.
A Windows DLL is ready for testing.
It should include the certs listed in this bug.

Please click here to download it: attachment 295966 [details]

You will download a zip file.
Please extract the file.
You will get a file named nssckbi.dll
It should have a file size of 294912 bytes (technical detail: md5sum 6afef34fd2b6b1c3309e10b6f74bd158)

In order to test, please get a build of Firefox 2.0.0.x for Windows.
Install it.
Quit Firefox.
Then find the directory that contains nssckbi.dll
Replace the file with the one you downloaded from this bug.

Start Firefox.
Open certificate manager.

It should show your new certs.
Dear Frank, Dear Kai,

Thank you very much for your efforts; we are really satisfied and delighted.
As a representative of TURKTRUST, I confirm that all the data in this bug is
correct, and that the correct certificates have been attached. Windows platform is fine for us to perform the verification steps.
We have obtained the "nssckbi.dll" (md5sum=6afef34fd2b6b1c3309e10b6f74bd158) and replaced the old dll with the new one. Both roots appeared in the certificate manager with correct information inside them. Everything is fine upto now. 
At this point, I have some questions regarding the subordinate (intermediate) roots. Does the system automatically recognizes the subordiante roots of the CA roots? All the certificates given by us (Qualified, server, object signing) are issued by corresponding subroot. 
"http://www.turktrust.com.tr/e/en51.jsp" illustrates the trust hierarchy of our firm. When a Firefox browser connects to an SSL site, does there exist an implicit mechanism that checks the Authority Info Access extension of the SSL certificate, get the issuer subroot from the site of CA using this link, and verify the subroot with a registered root certificate? This is how Internet Explorer works.  Elsewhere, what kind of a mechanism works for verifying certificates issued by subordinate roots? Should the subordinate roots also be included in the dll as well?
I have asked those questions since our Firefox with your new dll did not recognize the site "https://www.turktrust.com.tr" as an example. Our SSL certificate is issued by our subordinate certificate "TÜRKTRUST Elektronik Sunucu Sertifikasi Hizmetleri" which was issued by one of our Mozilla-registered roots. Hence we have failed while testing SSL certs?
We would be glad if you enlight those doubtful cases related to subroots.

Best wishes, kind regards,

Mert ÖZARAR
TÜRKTRUST Representative(In reply to comment #4)
> My apologies, the procedure I outlined above is incorrect; thanks to Kai for
> pointing me to the correct procedures.
> 
> The steps are as follows:
> 
> 1) A representative of the CA must confirm that all the data in this bug is
> correct, and that the correct certificate(s) have been attached. They must also
> specify what OS they would like to use to perform the verification below.
> 
> 2) A Mozilla representative creates a test build of NSS with the new
> certificate(s), and attaches nssckbi.dll to this bug. A representative of the
> CA must download this, drop it into a copy of Firefox and/or Thunderbird on the
> OS in question and confirm (by adding a comment here) that the certificate(s)
> have been correctly imported and that websites work correctly.
> 
> 3) The Mozilla representative checks the certificate(s) into the NSS store, and
> marks the bug RESOLVED FIXED.
> 
> 4) At some time after that, various Mozilla products will move to using a
> version of NSS which contains the certificate(s). This process is mostly under
> the control of the release drivers for those products.
> 

(In reply to comment #8)
> At this point, I have some questions regarding the subordinate (intermediate)
> roots. Does the system automatically recognizes the subordiante roots of the CA
> roots? 

When given a valid chain, NSS will verify across subordinate/intermediate certs.


> When a Firefox browser connects to an SSL site, does there exist an
> implicit mechanism that checks the Authority Info Access extension of the SSL
> certificate, get the issuer subroot from the site of CA using this link, and
> verify the subroot with a registered root certificate? 

Not as of today. We might add that later.
But right now, we require that SSL servers are configured to supply all intermediate certs together with the end entity cert.


> Elsewhere, what kind of a mechanism works for verifying
> certificates issued by subordinate roots? 

Not sure I understand this question.


> Should the subordinate roots also be
> included in the dll as well?

No, subordinate/intermediate certs are supposed to be provided by SSL servers. That is, when a server admin configures the new end entity cert, they must include the intermediate certs, too.


> I have asked those questions since our Firefox with your new dll did not
> recognize the site "https://www.turktrust.com.tr" as an example. Our SSL
> certificate is issued by our subordinate certificate "TÜRKTRUST Elektronik
> Sunucu Sertifikasi Hizmetleri" which was issued by one of our
> Mozilla-registered roots. Hence we have failed while testing SSL certs?
> We would be glad if you enlight those doubtful cases related to subroots.

The problem here is not related to subroots.
When I visit your site, I can see the server does provide the full chain and it chains up to your root.

The problem is:

Your "Root 1" is not marked trusted for web sites!!!

Please look at the first section in this bug, for "Root 1" it says:
   Trust flags: Email, Object signing

There is no "Web Sites" trust requested.
Frank, Mert, is the information listed in this bug incorrect, and do you want to have your "Root 1" to be trusted for "Web Sites" (SSl Servers) ?
Frank, and representatives of the CA:

I would like to propose one more detail for the verification steps.
Please ensure that correct "trust flags" are assigned to each new root certificate.

The requested trust flags are listed in the initial section of this bug report.
When using certificate manager, you can use the "edit trust" button to display the categories which are currently trusted.


Mert's comments suggest that TürkTrust expects that "Root 1" has trust for web sites assigned.
(In reply to comment #9)

> But right now, we require that SSL servers are configured to supply all
> intermediate certs together with the end entity cert.

That is a requirement of the IETF TLS RFC standard.  It is not a weakness
of NSS.  Nothing in the TLS RFCs, including the forthcoming TLS 1.2 RFC,
relaxes the requirement that TLS servers send a complete certificate chain. 
Frank, Kai;

You are definitely right, I have communicated with our system administrator and just realized that there exist some SSL certificates issued by Root 1 (the number is quite less than the number of certificates issued by Root 2, but we have to handle them). When we try another site ("https://www.aveamobilimza.com") whose SSL cert. was issued by Root 2, Firefox recognized and no problem occured. I apologize for my misleading question, Frank was definitely right. 

In this case, TürkTrust wants  "Root 1" has the ability to assure trust for web
sites as well as "Root 2". I hope it does not affect our submission period time length. Perhaps, Kai prepares us a second DLL in which "Root 1" is trusted for "Web Sites" as well and we can check it. 

Thank you for your patience and guidance, it is a good chance of us to work with you. I would be glad if you can help us for our extra request.

Kind regards,

MERT
I will wait for Frank to approve the additional trust flag. I have sent him private email.
(In reply to comment #14)
> I will wait for Frank to approve the additional trust flag. I have sent him
> private email.

My apologies for not responding earlier; I've been out of town on family business.

Root 1 is indeed approved for web sites, consistent with the original request from TURKTRUST and my comments in the inclusion bug 380635. It was an unfortunate oversight on my part that I left this trust flag out in my initial comment above. I apologize for missing this.
Frank;
We have tested the SSL web connections from our DLL-updated Firefox browsers to our existing customer sites that already have certificates under our Root 2 hierarchy.
Most of them work correctly, but we are getting the "website certified by an unknown authority" warning with some sites which have wildcard certificates (like *.aCompanyName.com.tr). 
Is there a special treatment for these certificates on Mozilla client site or any configuration needed while you are generating the updated "nssckbi.dll"?

Kai;
Shall we hope to wait for a new DLL with modified trust flag for Root 1 from you? else, what kind of process will take place to control the certificates issued by Root 1?

Best wishes,

MERT
Regarding treatment of wildcard certificates, that is a question better addressed to Kai Engert and the NSS developers in general. I don't know of any special configuration changes needed to make wildcard certificates work vs. non-wildcard certificates.
An updated nssckbi.dll is available, please download and extract this zip file:
attachment 296543 [details]

Please test whether this works correctly for, in particular, that it fixes your issues described in comment 8
(In reply to comment #16)
> Most of them work correctly, but we are getting the "website certified by an
> unknown authority" warning with some sites which have wildcard certificates
> (like *.aCompanyName.com.tr). 
> Is there a special treatment for these certificates on Mozilla client site or
> any configuration needed while you are generating the updated "nssckbi.dll"?

Can you please give a link to a site that uses such a wildcard cert and gives you an error message?
I want to mention, the md5sum for the new nssckbi.dll is: 2bfabe845871d2a20e4a8752c2156a5f
Unknown authority errors are what one would expect if the TLS server is not
sending out the intermediate CA certificates in its certificate chain. 
They are generally a symptom of a misconfigured server, one which has not 
been configured to send out the necessary intermediate CA certificates.
Kai;
Thanks a lot for your efforts, the problems concerning Root 1 have been handled with the new DLL. 

The two sites in which our SSL certificates (under Root 2) continue to give warnings are:

"https://owa.ulker.com.tr" with a wildcard certificate CN = *.ulker.com.tr

"https://mail.bedas.gov.tr" with a standard certificate CN = mail.bedas.gov.tr

If you can infer that those servers were misconfigured and the problem is at client side, then I will communicate with customers to solve the errors.

p.s. Let me remark that one is with wildcard other is with standard cert...

Kind regards,

MERT

(In reply to comment #19)
> (In reply to comment #16)
> > Most of them work correctly, but we are getting the "website certified by an
> > unknown authority" warning with some sites which have wildcard certificates
> > (like *.aCompanyName.com.tr). 
> > Is there a special treatment for these certificates on Mozilla client site or
> > any configuration needed while you are generating the updated "nssckbi.dll"?
> 
> Can you please give a link to a site that uses such a wildcard cert and gives
> you an error message?
> 

Mert, both servers are configured incorrectly.

During the SSL handshake, both servers send their server cert ONLY.
They do NOT send the intermediate required to chain up to the root.

I found the intermediate on your web site.
I clicked the following link:
http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sunucu_Sertifikasi_Hizmetleri_s2.crt

I installed that intermediate, but I did NOT check any trust checkboxes.

After I did that, I was successfully able to connect to both servers.

The servers must be configured to include that intermediate cert.


I conclude that you have confirmed the DLL works correctly and that we can proceed adding them.
Thank you very much Kai for your comments. I understood the problem better now.
We confirm that DLL works correctly and that you can proceed adding them.
What will be the next step? Can you give me an approximate time line of the coming processes? Shall  we wait for the next update? When will be the next update?
I asked those questions since our customers do want to learn the exact time.

Thanks again, kind regards,

MERT
I want to emphasize that the steps that Kai described in comment 23,
including downloading an intermediate CA cert into the browser, are 
diagnostic steps only, and are NOT steps recommended for browser users.  

The correct solution is for the servers to be configured to send out their
intermediate certificates.
Thanks Nelson, I got the point with your useful comments :)

best wishes,

MERT
Dear Frank,

Could you please give me an approximate time schedule for the remaining process? Our customers expect an exact time from me, so it would be better at least replying them with an answer like "before March, 2008" or "in the range of 10-15 February 2008". I will forward your schedule to them to prove that we are very close to reach our target.
Thank you very much for the answer.

best wishes,

MERT
(In reply to comment #27)
> Could you please give me an approximate time schedule for the remaining
> process?

Unfortunately I cannot give you an exact schedule, but here is an overview of what I think is a likely schedule:

First, your root needs to be added to the NSS trunk (i.e., the latest development version of NSS). That appears to have already been done.

Next, a version of NSS containing your root needs to be included in both Firefox 2 and Firefox 3.

I believe that Firefox 3 (which is still in development) now includes the version of NSS with your root. If this is the case, then your root will show up in Firefox beta 3 release, which should be available within the next week or two. There will then be a Firefox 3 beta 4 release, followed by the official Firefox 3 final release.  I'm not exactly sure when the Firefox 3 final release will be available; it may not be released until April or May or even later.

As for Firefox 2, my hope is that a new version of NSS containing your root can be included in one of the update releases of Firefox 2. (I think that Kai knows more about whether this is possible or not.) The next Firefox 2 update release will be 2.0.0.12, and will be available in a week or so. I think that your root was added too late to be included in that update. The next Firefox 2 update release will be 2.0.0.13; that will be the earliest update release in which your root could be included. New Firefox 2 update releases are created every month or two on average, so Firefox 2.0.0.13 may not be released until late March or early April.

I hope this answers your question.

Thank your very much for your answer Frank...
Kai;
Do you have any idea about new version of NSS containing our root can
be included in soonest update release of Firefox 2? 

I know we are quite enthusiastic and greedy :) about the time schedule since there is a great pressure on us, since we have spent so much time (~10 months) to qualify and most of our customers have started to prefer other companies for their SSL certificates even though their QEC had been issued by us. They have asked to be reached via Firefox to their sites and have unfortunately thought that we have technical or administrative difficulties. 

It will be amazing if we exist in the Mozilla store starting with 2.0.0.12.

Hope to get positive answers from you, best wishes and thanks for you efforts,

MERT
An updated snapshot that includes your root 
has been proposed for inclusion with firefox 2.0.0.13 in bug 416202.
This was fixed by bug 411299.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.11.9
You need to log in before you can comment on or make changes to this bug.