Closed Bug 944783 Opened 6 years ago Closed 3 years ago

Add LuxTrust Global Root CA Certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ca, Assigned: kwilson)

References

Details

(Whiteboard: In NSS 3.28.1, Firefox 51. EV-enabled in Firefox 54.)

Attachments

(11 files, 3 obsolete files)

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; MS-RTC LM 8; InfoPath.3)

Steps to reproduce:

LuxTrust S.A. was established in November 2005 in Luxembourg and provides Public Key Infrastructure (PKI) services for the whole economic marketplace in Luxembourg, for both private and public organisations. LuxTrust is the only CA in Luxembourg.

The LuxTrust Global Root CA Certificate is not currently recognized by Mozilla and consequently LuxTrust would like to launch the process for the inclusion of the SSL and Code Signing certificates in Mozilla trusted list. 

Please note that the bug report will be later updated with the EV SSL validation type (estimated planning: Q1 2014).



Actual results:

N/A


Expected results:

N/A
I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and provide the necessary information in this bug.
Dear Kathleen,

please find attached the CA Information document updated with the information requested.

Regards,

Yves,
Attached file Completed CA Information Document (obsolete) —
I'll try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: Information incomplete → Information confirmed complete
According to my notes, the new audits (including the BR audit) were expected to complete in March. What is the status of those audits?

Also, there was a previous indication that you would add EV validation in Q1 2014. Has that happened? Are your current audits including an EV audit?
Currently we have the EDP report based on the CWA 14167-1, this is an external audit done by Deloitte Luxembourg.

We are in the process of our internal ETSI assessment against TS101 456, 102 042 and 102 023. The EV validation is in the scope (ETSI 102 042 V2.4.1)

The certification audit is planned from 31/03 to 04/04. This audit will be done by LSTI (http://www.lsti-certification.fr/)

Yves
Since we have to wait for an audit that includes the BR audit, we should also wait for the EV audit and include EV-treatment in this request. 

Please add a comment to this bug when the audit statements are available.
Whiteboard: Information confirmed complete → EV -- need BR and EV audits
Also please update the test website to use an EV SSL cert, and do the EV testing as described here: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Let me know if you need help creating the test_ev_roots.txt file.
The audit on site is done. The auditors have received our answer and are now writing the final report.

We have successfully tested our Ev certificate based on 
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version 
and published the EV SSL cert on our site trusme.lu.
(In reply to ca from comment #10)
> The audit on site is done. The auditors have received our answer and are now
> writing the final report.

Great. Please update this bug with links to the audit statements when they are ready.

> 
> We have successfully tested our Ev certificate based on 
> https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version 
> and published the EV SSL cert on our site trusme.lu.

Please attach a screenshot showing successful EV treatment.

I'm not sure what the EV policy OID is...
For https://www.trustme.lu/ the intermediate cert has policy OID 1.3.171.1.1.1.10.5 and the end-entity cert has policy OID 1.3.171.1.1.10.5.2

https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F
The EV Policy OID in the end-entity and intermediate certificates must match the 2_readable_oid field in the test_ev_roots.txt file. (Note: the intermediate cert can use the anyPolicy oid rather than the EV policy oid.) 


I also noticed that there is no OCSP URI in the AIA of the intermediate cert.
1] We will update the audit statements as soon as we receive them from the auditors.

2] The screenshot is attached.

3] LuxTrust's strategy is having one sub-ca per 'domain' (please refer to LuxTrust Global Root CP p10, current version for this comment : https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1.15.pdf). 

Each CA issues with different profiles of certificates in its domain (please refer to LuxTrust Global Root CP, section 3.1  for the details on these profiles).

In the same document, p10, we specify that 
- each sub-ca has the OID 1.3.171.1.1.1.10.x where x identifies the sub CA.
- each certificate profile has the OID 1.3.171.1.1.10.x.y where x identifies the sub-ca which it refers and y the profile.

The SSL CA is dedicated to certificates for which the key pair is generated by the end-entity and the domain relates to object/ssl type.

This is the main reason why LuxTrust SSL CA has the policy OID 1.3.171.1.1.1.10.5 whereas the EV Certificates have the policy OID 1.3.171.1.1.10.5.2.

4] No OCSP URI in the AIA of the intermediate cert  :

The CA/B Forum baseline requirements BR v1.1.5 in its appendix B requires that the Subordinate CA certificate contain an OCSP URI in its Authority Information Access field. As stated in the foreword of the appendix B, this requirement applies to Certificates generated after the effective date of the BR.

LuxTrust SSL CA was generated on 22nd of November 2011, before the effective date of the first version v1.0.0 of the BR.

This is the main reason why these specific requirements were not addressed at the date of LuxTrust SSL CA generation.

We will implement this specific requirements in the next SSL CAs.
Please update this bug with your response to the recent CA Communication,
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014
1 Correct link to your most recent audit statement
=> We plan to send Mozilla our current audit statement by mid of june

2 Link to your most recent Baseline Requirements audit statement	
=> We plan to send Mozilla our current Baseline Requirements audit statement by mid of june, the auditors having some delay in writing their final report.

3 Test Mozilla's new Certificate Verification library	
=> We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix  for LTQCA.

4 Check your certificate issuance
=> We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page

5 Send Mozilla information about your publicly disclosed subordinate CA certificates
=> Cf. Bug 944783 plus attached document for the SSL CA (cf.SSL CA 2014_05_30.pdf) . This CA is in the scope of the audit. The external audit report will be available mid of june.

Additionally, please respond with one of the following	
=> All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy
(In reply to ca from comment #12)
> Created attachment 8420789 [details]
> screenshot showing successful EV treatment on trustme.lu

Which EV Policy OID did you put into the test_ev_roots.txt file?


(In reply to ca from comment #13)
> 1] We will update the audit statements as soon as we receive them from the
> auditors.

Please update this bug when the audit statements are available.
Please find hereby the detail of the test_ev_roots.txt file :

1_fingerprint B2:F2:D0:86:30:DE:6E:D0:5E:C3:78:F1:88:C3:61:F9:3F:A2:F8:85
2_readable_oid 1.3.171.1.1.10.5.2
3_issuer MEQxCzAJBgNVBAYTAkxVMRYwFAYDVQQKEw1MdXhUcnVzdCBzLmEuMR0wGwYDVQQDExRMdXhUcnVzdCBHbG9iYWwgUm9vdA==
4_serial DJg=

we have received the report, we are waiting for the final audit statement.
Depends on: 1060863
This certification (doc : 11085V1_LUXTRUST_V3_signé.pdf) covers our LuxTrust Global Root self-signed CA and also the EV SSL requirements for certificates issued under the LuxTrust SSL CA signed by our self-signed root CA (LuxTrust Global Root)
This certification is published under : //www.lsti-certification.fr/images/fichiers/11085.pdf
We recently created a new wiki page:
https://wiki.mozilla.org/CA:BaselineRequirements

Please review it with your auditor, and update this bug when that has happened.
Thank you for this update. We have launched the review and we will come back with an answer shortly.

Yves
(In reply to ca from comment #12)
> Created attachment 8420789 [details]
> screenshot showing successful EV treatment on trustme.lu

We have a new tool for testing EV-readiness, so I tried it with:
https://www.trustme.lu/ 
LuxTrustGlobalRoot.cert
1.3.171.1.1.10.5.2

And I got this error: BuildCertChain failed: SEC_ERROR_POLICY_VALIDATION_FAILED
Cert chain fails policy validation
It appears be the case that the end-entity certificate was issued directly by the root. There should be at least one intermediate in the certificate issuance chain.

The wiki page has been updated to explain how to use the new EV-readiness test:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
No longer depends on: 1060863
Items needing resolution before starting public discussion:
1) New EV-readiness test (Comment #23)
2) Confirm review of CA:BaselineRequirements wiki page with auditor (Comment #21)
3) Indication that the audit of the SSL certificates/hierarchy included the Baseline Requirements criteria (e.g. PTC-BR)
4) Question about the BR Commitment to comply: SSL CPS seems to indicate the BR commitment is regarding EV certs only. What about non-EV SSL certs? (those also need to comply with the BRs.
Please find below our answers to the four items needing resolution :
1) New EV-readiness test (Comment #23)
Regarding the website https://www.trustme.lu, we can confirm that the end-entity certificate is not issued directly from the “Global Root CA”, but it’s issued by the “LT SSL CA”.
We performed on our side the EV readiness tests with Mozilla’s new tool and identified the root cause of the issue:
- There is no OCSP reference in the AIA field of the intermediate CA “LT SSL CA “
As we mentioned in the comment 13 of the present bug report, the reason why this requirement is not addressed is that the current intermediate “LT SSL CA” was generated on 22nd of November 2011, before the effective date of the first version v1.0 of the BR.
The SSL CA will be renewed shortly and will include appropriate correction for this issue.

2) Confirm review of CA:BaselineRequirements wiki page with auditor (Comment #21)
We will finalize the review with our auditor and come back with an answer shortly.

3) Indication that the audit of the SSL certificates/hierarchy included the Baseline Requirements criteria (e.g. PTC-BR)
The audit statement issued by LSTI and provided in comment 19 covers the following OIDs:
Luxtrust SSL CA 1.3.171.1.1.10.5.1
Authentification serveur
ETSI TS 102 042 OVCP
Given that ETSI TS 102 042 V2.4.1 states in section 3.2 Abbreviations:
• PTC-BR Publicly-Trusted Certificate- Baseline Requirements
• NOTE: Within the context of the present document PTC-BR is used synonymously with DVCP and OVCP.
We considered that PTC-BR is addressed in the audit statement issued by LSTI.

4) Question about the BR Commitment to comply: SSL CPS seems to indicate the BR commitment is regarding EV certs only. What about non-EV SSL certs? (those also need to comply with the BRs).
We have updated the LT SSL CA CPS to include in the scope of the BR commitment certificates intended to be used for authenticating servers accessible through the Internet.
The LT SSL CA CPS v1.2 is published on LuxTrust’s web repository https://www.luxtrust.lu/fr/repository.
(In reply to ca from comment #26)
> Please find below our answers to the four items needing resolution :
> 1) New EV-readiness test (Comment #23)
> Regarding the website https://www.trustme.lu, we can confirm that the
> end-entity certificate is not issued directly from the “Global Root CA”, but
> it’s issued by the “LT SSL CA”.
> We performed on our side the EV readiness tests with Mozilla’s new tool and
> identified the root cause of the issue:
> - There is no OCSP reference in the AIA field of the intermediate CA “LT SSL
> CA “
> As we mentioned in the comment 13 of the present bug report, the reason why
> this requirement is not addressed is that the current intermediate “LT SSL
> CA” was generated on 22nd of November 2011, before the effective date of the
> first version v1.0 of the BR.
> The SSL CA will be renewed shortly and will include appropriate correction
> for this issue.


OK. Please update this bug when that has happened.


> 
> 2) Confirm review of CA:BaselineRequirements wiki page with auditor (Comment
> #21)
> We will finalize the review with our auditor and come back with an answer
> shortly.
> 

OK


> 3) Indication that the audit of the SSL certificates/hierarchy included the
> Baseline Requirements criteria (e.g. PTC-BR)
> The audit statement issued by LSTI and provided in comment 19 covers the
> following OIDs:
> Luxtrust SSL CA 1.3.171.1.1.10.5.1
> Authentification serveur
> ETSI TS 102 042 OVCP
> Given that ETSI TS 102 042 V2.4.1 states in section 3.2 Abbreviations:
> • PTC-BR Publicly-Trusted Certificate- Baseline Requirements
> • NOTE: Within the context of the present document PTC-BR is used
> synonymously with DVCP and OVCP.
> We considered that PTC-BR is addressed in the audit statement issued by LSTI.


I see. I appreciate that LSTI has begun adding PTC-BR to make this more clear:
http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
(search for PTC-BR)


> 
> 4) Question about the BR Commitment to comply: SSL CPS seems to indicate the
> BR commitment is regarding EV certs only. What about non-EV SSL certs?
> (those also need to comply with the BRs).
> We have updated the LT SSL CA CPS to include in the scope of the BR
> commitment certificates intended to be used for authenticating servers
> accessible through the Internet.
> The LT SSL CA CPS v1.2 is published on LuxTrust’s web repository
> https://www.luxtrust.lu/fr/repository.

Thanks!
(In reply to ca from comment #26)
> Please find below our answers to the four items needing resolution :
> 1) New EV-readiness test (Comment #23)
> Regarding the website https://www.trustme.lu, we can confirm that the
> end-entity certificate is not issued directly from the “Global Root CA”, but
> it’s issued by the “LT SSL CA”.
> We performed on our side the EV readiness tests with Mozilla’s new tool and
> identified the root cause of the issue:
> - There is no OCSP reference in the AIA field of the intermediate CA “LT SSL
> CA “
> As we mentioned in the comment 13 of the present bug report, the reason why
> this requirement is not addressed is that the current intermediate “LT SSL
> CA” was generated on 22nd of November 2011, before the effective date of the
> first version v1.0 of the BR.
> The SSL CA will be renewed shortly and will include appropriate correction
> for this issue.

The SEC_ERROR_POLICY_VALIDATION_FAILED error comes from the CertificatePolicies chaining. PolicyId OID 1.3.171.1.1.10.5.2 isn't granted by the root to the intermediate CA.
Please find a status on the last item needing resolution before starting public discussion :
1)      New EV-readiness test
We renewed the LuxTrust SSL CA in order to include the OCSP reference in the AIA field and the “anyPolicy” extension (OID: 2.5.29.32.0).
The LuxTrust Certificate Policy has been updated accordingly in v1.20 and is published on LuxTrust repository web site.
We are currently performing EV-readiness tests for this new certificate with Mozilla’s testing tool.
In addition, the EV SSL certificate for www.trustme.lu will be published on 29/12 at the latest.
 
We will update the bug report when the aforementioned actions are complete. Please let us know when / if the public discussions can be launched.
 
Best regards,
The EV server certificate was put in place for www.trustme.lu.

The EV-readiness test (http://cert-checker.allizom.org/) has been run successfully. The output was as follows:

// CN=LuxTrust Global Root,O=LuxTrust s.a.,C=LU
"1.3.171.1.1.10.5.2",
"EV Check",
SEC_OID_UNKNOWN,
{ 0xA1, 0xB2, 0xDB, 0xEB, 0x64, 0xE7, 0x06, 0xC6, 0x16, 0x9E, 0x3C, 
  0x41, 0x18, 0xB2, 0x3B, 0xAA, 0x09, 0x01, 0x8A, 0x84, 0x27, 0x66, 
  0x6D, 0x8B, 0xF0, 0xE2, 0x88, 0x91, 0xEC, 0x05, 0x19, 0x50 },
"MEQxCzAJBgNVBAYTAkxVMRYwFAYDVQQKEw1MdXhUcnVzdCBzLmEuMR0wGwYDVQQD"
"ExRMdXhUcnVzdCBHbG9iYWwgUm9vdA==",
"C7g=",
Success!
(In reply to ca from comment #26)
> 3) Indication that the audit of the SSL certificates/hierarchy included the
> Baseline Requirements criteria (e.g. PTC-BR)
> The audit statement issued by LSTI and provided in comment 19 covers the
> following OIDs:
> Luxtrust SSL CA 1.3.171.1.1.10.5.1
> Authentification serveur
> ETSI TS 102 042 OVCP
> Given that ETSI TS 102 042 V2.4.1 states in section 3.2 Abbreviations:
> • PTC-BR Publicly-Trusted Certificate- Baseline Requirements
> • NOTE: Within the context of the present document PTC-BR is used
> synonymously with DVCP and OVCP.
> We considered that PTC-BR is addressed in the audit statement issued by LSTI.

Please discuss this with LSTI, and request that PTC-BR be specifically indicated in future audit statements and annual onsite surveillance statements.
I'm confused about the role of RAs. Can RAs directly cause the issuance of SSL and EV SSL certificates? What checks are in place to ensure proper domain name verification for SSL certs?

My notes say: "Regarding applicative certificates (SSL and code-signing), only LuxTrust and the Chamber of Commerce of Luxembourg are entitled to authenticate and authorize certificate creation.

However, I'm not finding that in the SSL CPS. In particular section 3.2.2 seems to indicate that all RAs can do the domain control verification and cause SSL and EV SSL certs to be issued.

Also, My notes say: "for compliance with ETSI 101 456, all RAs are subject to regular audits."

But for SSL certificate issuance Mozilla policy requires the audit criteria to be ETSI 101 042 (with PTC-BR) or WebTrust CA (and BR).

Please clarify.
(In reply to Kathleen Wilson from comment #32)
Correction of typo...
"But for SSL certificate issuance Mozilla policy requires the audit criteria to be ETSI TS 102 042 (with PTC-BR) or WebTrust CA (and BR)."
Whiteboard: EV -- need BR and EV audits → EV
Please find below an answer following your questions raised in the comments #31, #32 and #33.
1.PTC-BR : 
This topic has been discussed with LSTI and we will request that future audit statements and annual onsite surveillance statements specifically mention PTC-BR.

2.RA for SSL, EV SSL and Code signing certificates:
We confirm that the only RAs issuing SSL, EV SSL and code signing certificates are “LuxTrust S.A.” and “Chambre de Commerce“.
The SSL CA CPS mentions, respectively in its sections 3.2.2 and 1.3.2, that:
•“RAs operating under the LuxTrust SSL CA shall perform a verification of any organizational identities that are submitted by an Applicant or Subscriber.”
•“The list of the authorised RAs governed by this CPS is published on LuxTrust’s website https://www.luxtrust.lu.”
In addition, LuxTrust’s web site https://www.luxtrust.lu/en/simple/206 mentions that the RAs issuing SSL, EV SSL and code signing certificates are “LuxTrust S.A.” and “Chambre de Commerce.”

3.Regular audits
We confirm that LuxTrust and the RA issuing SSL, EV SSL and code signing certificates under LuxTrust SSL CA are yearly audited against ETSI TS 102 042 with OVCP and PTC-BR.
The SSL CA CPS mentions, respectively in its sections 8  and 9.6.1:
•"With regards to the provision of LuxTrust Certificates, LuxTrust S.A. through its LuxTrust SSL CA operates:
- According to the ETSI technical standard TS 102 042, [3]." 
•"LuxTrust S.A., through its LuxTrust SSL CA issues Certificates compliant with ETSI TS 102 042 Certificates requirements."

Regarding the EV-readiness test, topic addressed in the comment #29 :
We generated a new SSL CA 4 and issued an EV certificate for the website www.trustme.lu.
The EV-readiness test has been run successfully on this website.

Based on the above mentioned answers, could you please let us know when the public discussions can be launched ?
Attached file Completed CA Information Document (obsolete) —
I have entered the information for this request into SalesForce, so you will notice a different format in the attached document. Please review to check for accuracy and completeness.
Attachment #8371119 - Attachment is obsolete: true
Whiteboard: EV → EV - Ready for Public Discussion
I am now opening the first public discussion period for this request from LuxTrust to include the “LuxTrust Global Root” root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “LuxTrust Root Inclusion Request”.

Please actively review, respond, and contribute to the discussion.

A representative of LuxTrust must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Ready for Public Discussion → EV - In public discussion
The first discussion of this request is now closed, and the following action items resulted from the discussion.

1) Resolve the concerns that were raised about CRL and OCSP.
Also resolve all errors listed here: https://certificate.revocationcheck.com/www.trustme.lu

2) Stop issuing certs with SHA-1 based signatures, and certs with "Netscape Cert Type" extension (especially in this CA hierarchy) 

3) Update the CPS documents to respond to Ryan's comments in the discussion
https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ
In particular his comments:
-- Names in non-SSL certificates
-- Cross-signing
-- Trademarks
-- Revocation Requests/Requirements
-- ETSI Status
-- Certificate Transparency

A representative of LuxTrust should update this bug when these items have been resolved.

Then I will verify the completion of the items, and start a second discussion.
Whiteboard: EV - In public discussion → EV - Responding to First Discussion
A representative of LuxTrust posted their initial response to these action items in the discussion, here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/erw3ToheAQAJ

To summarize:

> 1) Resolve the concerns that were raised about CRL and OCSP.

LuxTrust plans the implementation of ... solutions by the end of January 2016 

> 2) Stop issuing certs with SHA-1 based signatures, and certs with "Netscape Cert Type" extension (especially in this CA hierarchy) 

LuxTrust confirms that no SSL and code-signing certificate issued under the LTGRCA hierarchy use the SHA-1 hash algorithm, as described in the SSL and code signing profiles of the LTGRCA CP v1.22.
Netscape Cert Type: LuxTrust confirms that the certificates issued under the LTGRCA hierarchy do not contain the “Netscape Cert Type” extension, as described in the certificate profiles of the LTGRCA CP v1.22. 

> 3) Update the CPS documents to respond to Ryan's comments in the discussion

To address these concerns, LuxTrust has updated their CP/CPS documents, and provided them on their website:

Document Repository: https://repository.luxtrust.lu

LTGRCA CP v1.22: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf

LTGRCA CPS v1.09: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf

LTSSLCA CPS v1.3: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf
I started the second discussion here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/cs8nIChS0dY/lYYuWAA2BAAJ

Please provide links to the 2015 audit statements as soon as possible.
Whiteboard: EV - Responding to First Discussion → EV - In Second Discussion
Dear Kathleen,

The 2015 audit statements provided by LSTI are available at the following link : https://www.luxtrust.lu/upload/data/repository/Attestation_luxtrust_13082015.pdf.

Best regards,
We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
ERROR: basicConstraints must be critical in CA certificates 

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://www.trustme.lu/'

Using certificate from local file 'LuxTrustGlobalRoot.cert'

    /C=LU/1.3.6.1.4.1.311.60.2.1.3=LU/ST=Luxembourg/L=Capellen/O=LuxTrust S.A./businessCategory=Private Organization/serialNumber=B112233
        Informational
            EV certificate identified
            TLS Server certificate identified

    /C=LU/O=LuxTrust S.A./CN=LuxTrust SSL CA 4
        Error
            basicConstraints must be critical in CA certificates
            CA certificates must set keyUsage extension as critical
        Warning
            Extension should be critical for KeyUsage
            Serial numbers should have at least 20 bits of entropy
            CA certificates should include Digital Signature to allow signing OCSP responses
        Informational
            CA certificate identified

    /C=LU/O=LuxTrust s.a./CN=LuxTrust Global Root
        Error
            basicConstraints must be critical in CA certificates
        Warning
            Serial numbers should have at least 20 bits of entropy
~~

Please add a comment in this bug when the errors have been resolved.
(In reply to Kathleen Wilson from comment #41)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/
Regarding the error raised about the LT Global Root CA :
•         The LT Global Root CA was generated on 17th March 2011. The basicConstraints extension requirement was adopted in the CA/B Forum BR v1.0 on 22nd November 2011 and considered effective starting from 1st July 2012, subsequently to the setup of the LT Global Root CA. Consequently, the basicConstraints extension requirement could not be implemented during the creation of the LT Global Root CA.
•         Nevertheless, for replacing this LT Global Root CA, LuxTrust implemented a new LT Global Root CA 2 on 05th March 2015, which is compliant with this CA/B Forum extension requirement. The LT Global Root CA 2 respects the same CP and CPS as the LT Global Root CA (available on LuxTrust’s web repository https://www.luxtrust.lu/fr/repository), relies on the same technical environments and is subject to the same ETSI certifications (cf. audit statement https://www.luxtrust.lu/upload/data/repository/Attestation_luxtrust_13082015.pdf). The LT Global Root CA 2 is in process for replacing the LT Global Root CA in the inclusion process (the bug report will be updated when completed). Could you please confirm that, for increasing compliance, continuing the current inclusion request with the new LT Global Root CA 2 is acceptable for Mozilla?
Regarding the error raised about the LT SSL CA 4, LuxTrust has already planned the corrective actions and will thus issue, in a short timeframe, a new LT SSL CA 5 compliant with the CA/B Forum extensions requirement under the LT Global Root CA 2.
Then, LuxTrust will implement on the test website a SSL certificate chaining up to the new root CA hierarchy.
The bug report will be updated when the above-mentioned actions are completed.
Dear Kathleen,

Please allow us to come back to you with a very kind reminder regarding our question in the previous comment :
Could you please confirm that, for increasing compliance, continuing the current inclusion request with the new LT Global Root CA 2 is acceptable for Mozilla?
Thanks Kathleen for your reply.

Best regards,
(In reply to ca from comment #44)
> Could you please confirm that, for increasing compliance, continuing the
> current inclusion request with the new LT Global Root CA 2 is acceptable for
> Mozilla?

Yes.

Please provide the following information for the LT Global Root CA 2 certificate:
1) Root Cert Download URL
2) Test Website URL whose EV SSL cert chains up to this Root CA 2.
3) Successful result of https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Dear Kathleen,

Thanks for your reply.
Please find below our answers to your request :
1) The download URL for LT Global Root CA 2 is: https://www.luxtrust.lu/fr/simple/191
For 2) and 3), and as mentioned in our previous comments, we will provide you with these information when the test website is implemented with a SSL certificate chaining up to the LT Global Root CA 2 hierarchy.

Best regards,
Whiteboard: EV - In Second Discussion → EV - Second discussion on hold -- awating information relating to updated root cert
Dear Kathleen,

Regarding the pending actions raised in the present bug report, LuxTrust addressed all the topics as follows:
    • A new LT SSL CA 5 compliant with the CA/B Forum extension requirement has been issued under the LT Global Root CA 2.
    • The following errors and warnings reported in the bug report are fixed with the new LT SSL CA 5:
        o   The LT SSL CA 5 certificate has “basicConstraints” and “keyUsage” extensions set as critical.
        o   The LT SSL CA 5’s serial number has 20 bits of entropy.

The test Website URL whose EV SSL cert chains up to the LT Global Root CA 2 is https://ltsslca5.trustme.lu

The EV tests performed using the following URL have shown no error messages:
    • https://cert-checker.allizom.org/https://cert-checker.allizom.org/ev-checkerhttps://certificate.revocationcheck.com/ltsslca5.trustme.lu

In addition, regarding the concerns raised about OCSP in the first public discussion, LuxTrust implemented a new OCSP solution. Following this implementation:
    • The issues related to the OCSP GET method are now fixed.
    • The issues related to the OCSP "good" responses for non-issued certificates are now fixed.
    • The new certificate profile for the OCSP signing certificate supports the “no check” extension.

In this new context where the issues are closed, would it be possible to proceed with the second public discussion ?

Thank you.

Best regards,
(In reply to ca from comment #47)
> Dear Kathleen,
> 
> Regarding the pending actions raised in the present bug report, LuxTrust
> addressed all the topics as follows:
>     • A new LT SSL CA 5 compliant with the CA/B Forum extension requirement
> has been issued under the LT Global Root CA 2.


Please review the document attached in Comment #48 and comment in this bug to let me know if any further updates are needed to reflect the new root, hierarchy, policies, etc.

>     • https://certificate.revocationcheck.com/ltsslca5.trustme.lu

Just tried this a few moments ago and got error: Response is not yet valid


> In this new context where the issues are closed, would it be possible to
> proceed with the second public discussion ?

We will be able to proceed with the second public discussion.
Dear Kathleen,

Regarding the error: “Response is not yet valid” as a result of the test with the URL: https://certificate.revocationcheck.com/ltsslca5.trustme.lu:
We raised the issue to the provider of our OCSP application and understood that the issue comes from a bug in the OCSP application.
The OCSP application provider is preparing a patch for correction of this issue and will deliver it in a short timeframe.
As soon as the patch is received, LuxTrust will apply it on the OCSP application.
The bug report will be updated when the correction is implemented on the OCSP application.

Best regards,
Dear Kathleen,

As mentioned in LuxTrust’s previous comment, the corrective patch was applied on the OCSP application.
The test with the URL : https://certificate.revocationcheck.com/ltsslca5.trustme.lu shows no more error.
Would it be possible to proceed with the second public discussion ?

Best regards,
Dear Kathleen,

After review of the document “944783-CAInformation-UpdatedRoot.pdf” attached in Comment #48, we would like to propose the following updates:
    • On the page 3, for the field “Root Stores Included In”: The LT Global Root CA 2 is not included yet in Microsoft Root store. The inclusion process for the LT Global Root CA 2 in Microsoft Root store is currently on-going and expected to be completed by Q4 2016.
    • On the page 5 , for the field “Other Relevant Documents” : The link to the Global Qualified CA CPS is : https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Qualified_CA_Certification_Practice_Statements_v1_07.pdf
    • On the page 6, for the field “Network Security” : “The network security controls are assessed on a regularly basis during the ETSI audits (yearly basis), the EDP full audits (previously on a three-year basis and against the EDP CWA 14167-1:2003 standard , now on a two-year basis as of June 2016 and against the CEN/TS 419 261:2015 standard) and other dedicated assessments.”

In addition, on the page 3 for the field “Revocation Tested”, may you please update the test result as mentioned in our previous comment #52?
Dear Kathleen,
Since the requested information about the “LuxTrust Global Root CA 2“ was provided and the issues raised during the first public discussion corrected, would it be possible to proceed with the second public discussion?
Thank you for your reply.

Best regards,
Attached file Completed CA Information Document (obsolete) —
Attachment #8559339 - Attachment is obsolete: true
Attachment #8777475 - Attachment is obsolete: true
Whiteboard: EV - Second discussion on hold -- awating information relating to updated root cert → EV - Second discussion resumed
The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical].	 
I am not aware of instances where LuxTrust has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
LuxTrust appears to provide a service relevant to Mozilla users. LuxTrust provides PKI services to the Financial Sector, and therefore is under regulation of the Luxembourg’s financial regulator: CSSF (Commission de Surveillance du Secteur Financier). End-entity certificates are issued to: Natural persons, in compliance with EU directive 1999/93/EC; and Private and public Organisations (incl. SSL and code signing).

LuxTrust previous Root CA was cross signed by Baltimore CyberTrust Root CA. In order for LuxTrust to provide a National Certification Authority service and in accordance with the Grand Duchy of Luxembourg’s strategy, LuxTrust decided to generate and deploy its own trusted Root CA (LuxTrust Global Root CA).

Root Certificate Name: LuxTrust Global Root 2
O From Issuer Field: LuxTrust S.A.
Trust Bits: Websites
EV Policy OID: 1.3.171.1.1.10.5.2
Root Certificate Download URL: https://ca.luxtrust.lu/LTGRCA2.crt

Certificate Revocation
CRL URL(s):
http://crl.luxtrust.lu/LTGRCA2.crl
http://crl.luxtrust.lu/LTSSLCA5.crl
SSL CPS section 4.9.7: A CRL is issued each 4 hours, at an agreed time.
OCSP URL(s):
http://ssl.ocsp.luxtrust.lu
http://ltgroot.ocsp.luxtrust.lu

CA Document Repository: 	https://repository.luxtrust.lu
CP: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf
CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf
Global Qualified CA CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Qualified_CA_Certification_Practice_Statements_v1_07.pdf
SSL CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf

Inclusion Policy Section 7 [Validation]. 
LuxTrust appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification Procedures: SSL CPS section 3.2.2: In the particular case of SSL, RAs operating under the LuxTrust SSL CA shall determine whether the domain referenced in the SSL Certificate application is owned and controlled by the subscriber.
LuxTrust validates that the Subscriber has the right to control the domain names using the following verification procedures:
[1] Communicating with the technical contact information provided by the Subscriber in the order form.
[2] Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
[3] Relying upon a Domain Authorization Document which contains the signature of an authorized representative of the domain holder, a date that is on or after the certificate request and a statement confirming the Subscriber’s control over the domain names in the certificate. LuxTrust also relies on a reliable third-party, the Chamber of Commerce of Luxembourg, to confirm the authenticity of the Domain Authorization Document.

* EV SSL Verification Procedures: SSL CPS section 3.2.2: In the particular case of EV SSL Certificates, RAs operating under the LuxTrust SSL CA shall determine whether the organizational identity, legal existence, physical existence, operational existence, and domain name provided with a LuxTrust EV SSL Certificate Application are consistent with the requirements set forth in the EV Guidelines published by the CA/Browser Forum. 

* Email Verification Procedures: The Email (S/MIME) trust bit is not requested.

* Code Signing Subscriber Verification Procedure: Mozilla is no longer accepting requests to enable the Code Signing trust bit, because we plan to remove the Code Signing trust bit in the next version of Mozilla's CA Certificate Policy.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by LSTI, according to the ETSI TS 102 042 criteria.
https://bugzilla.mozilla.org/attachment.cgi?id=8777887

Inclusion Policy Section 18 [Certificate Hierarchy]
LuxTrust Global Root CA signs internally-operated intermediate certificates which sign end-entity certificates.
	 
Based on this assessment I intend to approve this request from LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and enable EV treatment.
Whiteboard: EV - Second discussion resumed → EV - Pending Approval
As per the summary in Comment #58, and on behalf of Mozilla I approve this request from LuxTrust to include the following root certificate:

** "LuxTrust Global Root 2" (websites), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM changes
Depends on: 1307981
Depends on: 1307984
I have filed bug #1307981 against NSS and bug #1307984 against PSM for the actual changes.
Whiteboard: EV - Approved - awaiting NSS and PSM changes → In NSS 3.28.1, Firefox 51 - awaiting PSM changes for EV
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: In NSS 3.28.1, Firefox 51 - awaiting PSM changes for EV → In NSS 3.28.1, Firefox 51. EV-enabled in Firefox 54.
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.