Open Bug 1239329 Opened 4 years ago Updated 2 months ago

Add Renewed ACEDICOM root certificate(s)

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: rsantisteban, Assigned: kwilson)

Details

(Whiteboard: [ca-verifying] - KW Comment #35 2018-10-18)

Attachments

(11 files, 1 obsolete file)

CA Details
----------
Original bug inclusion bug number is 471045.

https://bugzilla.mozilla.org/show_bug.cgi?id=471045

CA Name: CAEDICOM ROOT
Website: https://acedicom.edicomgroup.com/en/index.htm
One Paragraph Summary of CA, including the following:
Edicom , and more specifically the Certification Authority ACEDICOM, is really interested on become a member o Mozilla Certificate Root program.
As Mozilla Certificate Policy describes 
ACEDICOM acomplish with all the requirements specified by Mozilla Policy and It would be really interesting for Mozilla products users include "ACEDICOM Root" Certificate.

In this bug EDICOM is applying for include renewed EDICOM Root, which is issued using SHA256 as following best practices. It's necessary that both Root can be together at Trusted Root repository as a transition time is required.

Last audit process covers both new and old Root Certificate Authorities chain.

Audit Type : Webtrust
Auditor: Auren
Auditor Website:http://www.auren.com/en-IN
Audit Document URL(s):https://cert.webtrust.org/ViewSeal?id=1958

Certificate Details
-------------------

Certificate Name: "CAEDICOM Root"
Summary Paragraph, including the following:
New Edicom Certification Authority tree is based on a Root CA (CAEDICOM Root), and a subordinate CA (CAEDICOM01) at this bug creation time.
CAEDICOM Root only issues certificates for subordinate CAs. Nowadays, only subCA "CAEDICOM01" certificate has been signed by "CAEDICOM ROOT".

Certificate Practices Statement can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf

Certificate Policy can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Extended key usages in end entity certificates issued CAEDICOM01 (the only subCA) are:
    * Server Authentication
    * Client Authentication
    * Secure E-mail

Section 3.1 , 3.2 and 3.3 of the Policy specifies the control process followed by Edicom Registration Authority operators to ensure identity accreditation as one of the steps of the issue process.



No external management or subCA is considered under Edicom CPS. No subordinate CA is managed by third party.

Certificate download URL (on CA website):
Version: 
SHA1 Fingerprint: 6C:29:BC:40:BC:0E:C3:7F:78:7E:94:BC:96:2B:C8:D1:FC:A3:58:E4
SHA256 Fingerprint:6D:F0:7B:6A:14:DC:38:44:7C:11:68:9A:FE:23:04:41:AA:F7:58:63:AE:FE:06:1D:48:92:E2:9B:94:1C:2F:51
Public key length (for RSA, modulus length) in bits: 4096
Valid From (YYYY-MM-DD): 2014-05-21
Valid To (YYYY-MM-DD): 2034-05-21

This Root has not be involved in cross signing.

CRL HTTP URL: http://acedicom.edicomgroup.com/caedicomroot.crl
CRL issuing frequency for subordinate end-entity certificates: 24 hours (CRLs issued by CAEDICOM01)
CRL issuing frequency for subordinate CA certificates: 90 days (CRLs issued by CAEDICOM ROOT)
OCSP URL: http://ocsp.acedicom.edicomgroup.com/caedicomroot

Requested Trust Indicators (email and/or SSL and/or code signing):
URL of example website using certificate subordinate to this root
https://rootcertificateprograms.edicom.es/

Problematic Practices (https://wiki.mozilla.org/CA:Problematic_Practices) and Recommended Practices (https://wiki.mozilla.org/CA:Recommended_Practices) are covered in the same way as the actual Root.
Summary: Add Renewed [ACEDICOM] root certificate(s) → Add Renewed ACEDICOM root certificate(s)
Management of the Problematic Practices described at https://wiki.mozilla.org/CA:Problematic_Practices

** Long-lived DV certificates **
2 years is the maximum valid certificate expiration data, as stated at section 7.1.2.5 of the Policy document.

** Wildcard DV SSL certificates **
The wilcards in names are not allowed. Thus, although wildcards, like CN =*.domain.tld , are common an accepted on the Internet, certificates containing a wildcard will not be issued under this policy. There is one exception: the certificates issued for domains under the control of the organization administering Edicom  it may contain wildcards and Edicom always have control of the domains and subdomains for which the organization
"3.1.7 Using wildcards in the names" of the Policy describe this.

** Delegation of Domain / Email validation to third parties **
Edicom own operators are in charge of domain/e-mail validation requirements described in sections 3.1 , 3.2 and 3.3 of the Policy

** Issuing end entity certificates directly from roots **
This is not allowed. "CAEDICOM Root" just issue subCA certificates.

** Allowing external entities to operate subordinate CAs **
No third party management is considered

** Distributing generated private keys in PKCS#12 files **
User keys are  generated by the user and then the user sends the certificate sign request, as specified on the following sections of the policy 6.1

** Certificates referencing hostnames or private IP addresses **
Special IP addresses (RFC 3330) are not allowed as a domain name on server certificates, as described 
on the section 3.1.1 of the policy.

** Issuing SSL Certificates for Internal Domains **
Internal Domains are not valid for CAEDICOM certificates, as described on the section 3.1.1 of the policy.

** OCSP Responses signed by a certificate under a different root **
OCSP responses are signed by Root certificate

** SHA-1 Certificates **
All certificates under this CA tree "CAEDICOM ROOT" -> "CAEDICOM01 " -> "End entity Certificate" use SHA256

** Generic names for CAs **
Subject of "CAEDICOM Root" describes perfectly the company:
CN=CAEDICOM01/serialNumber=B96490867, O=EDICOM, L=Calle Charles Robert Darwin 8 - 46980 - Paterna, C=ES

** Lack of Communication With End Users **
Different communication channels (website, e-mail, phone) are open for end-users or third party.
** Backdating the notBefore date **
"CAEDICOM Root" notBefore date is the same as issue date.
Management of Recommended Practices at "https://wiki.mozilla.org/CA:Recommended_Practices"

** Publicly Available CP and CPS **
CAEDICOM CP/CPS documents are publicly available at the official web site http://acedicom.edicomgroup.com
Certificate Practices Statement can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf
Certificate Policy can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Both documents are in PDF format and in English version.
References to this document are used across this bug documentation

** CA Hierarchy **

New Edicom Certification Authority tree is based on a Root CA (CAEDICOM Root), and a subordinate CA (CAEDICOM01) at this bug creation time.
CAEDICOM Root only issues certificates for subordinate CAs. Nowadays, only subCA "CAEDICOM01" certificate has been signed by "CAEDICOM ROOT".
End entity certificates are issued by "CAEDICOM01"

** Audit Criteria **
Audit public document is located at https://cert.webtrust.org/ViewSeal?id=1958
The audit is based on Webtrus plus CAB Forum Baseline requirements

** Document Handling of IDNs in CP/CPS **
No internationalized domain names are allowed at certificates issued by CAEDICOM.

** Revocation of Compromised Certificates **
Revocation of compromised Certificate procedures  procedures and causes are described at section 4.8 of the Certificate Practices Statement.

** Verifying Domain Name Ownership **
Section 3.1 , 3.2 and 3.3 of the Policy specifies the control process followed by Edicom Registration Authority operators to ensure identity accreditation as one of the steps of the issue process. This includes Domain name ownership verification.

** Baseline Requirements **
Audit statements indicates how CAEDICOM accomplish with Baseline Requirements

** WHOIS **
For domain validation whois services are used. Section 3.2 of the policy states that, administrative contact e-mail of whois is the information used to validate the domain.
In any case CAEDICOM reserves the right of require physical presence of the applicant or person authorized by him in the registration points in order to provide documentation and conduct appropriate identity checks, as detailed in de Certificate Practice Statement in 3.2.2 and 3.2.3


** Email Challenge-Response / Verifying Email Address Control **
For the e-mail validation, as described in such section, CAEDICOM will send an e-mail , which will include a non repeatable random key (challenge)
The e-mail receiver will respond using provided instruction, so using such challenge the response is matched with the initial e-mail validation process. Once the operator matches it, e-mail validation is completed.
These validation processes are mandatory for each certificate before issuing it.

** DNS names go in SAN **
Sample certificates have been validated by auditors to check that this requirements are satisfied

** Domain owned by a Natural Person **
Proposal is compatible with actual certificate profile.

** OCSP **
OCSP Server has been checked at the audit process.

** Network Security Controls **
Network Security Controls have been audited against "WebTrust Principles and Criteria  SSL Baseline with Network Security – Version 2."
Regular audits are planed and cover all the recommended points:
- Webtrust : annually . Public report available. Last one: https://cert.webtrust.org/ViewSeal?id=1958
- ISO27001 Certification: annually. Public report available.http://www.edicomgroup.com/es_ES/dms/Edicom/Certifications/ISO_27001/ISO%2027001.pdf
Beginning information verification as described here:
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
Attached file 1239329-CAInformation.pdf (obsolete) —
I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the attached document).
Additional information covers questions in the attachment "1239329-CAInformation.pdf"

Certificate Authorities of Edicom are targeted to private customers, legal or natural person. EDICOM works with companies worldwide to help them achieve ongoing growth and profits and is now the technology provider for B2B communications project development and data integration. Global market is the focus of Edicom certificate customers.

TLS CP is full translated into English. In can be reached throw https://acedicom.edicomgroup.com/en/index.htm 
and directly at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf

CP is now full translated into English, so for the Email Address Verification question, now the sections referenced can be reviewed in English.
Edicom own operators are in charge of domain/e-mail validation requirements described in sections 3.1 , 3.2 and 3.3 of the Policy
For domain validation whois services are used. Section 3.2 of the policy states that, administrative contact e-mail of whois is the information used to validate the domain.
In any case CAEDICOM reserves the right of require physical presence of the applicant or person authorized by him in the registration points in order to provide documentation and conduct appropriate identity checks, as detailed in de Certificate Practice Statement in 3.2.2 and 3.2.3
Attachment #8708137 - Attachment is obsolete: true
This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.
Whiteboard: Information incomplete → Ready for Public Discussion
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:
no errors (certificate not found via CT)

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://rootcertificateprograms.edicom.es/'

Using certificate from local file 'CAEDICOMRoot.cer'

    /CN=rootcertificateprograms.edicom.es
        Notice
            CN could be encoded as PrintableString
        Error
            Certificate Policy explict text must not be VisibleString or BMPString
            Unallowed key usage for RSA public key
~~

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

Test 2 moved to https://cert-checker.allizom.org/
Actual URL checks provides different output. Can you please confirm If we should work on this new output?



Using certificate chain from 'https://rootcertificateprograms.edicom.es/'

Using certificate from local file 'CAEDICOMRoot'

    /CN=rootcertificateprograms.edicom.es
        Warning
            Extension should be critical for KeyUsage
        Error
            Unallowed key usage for RSA public key
        Informational
            TLS Server certificate identified

    /CN=CAEDICOM01/serialNumber=B96490867/O=EDICOM/L=Calle Charles Robert Darwin 8 - 46980 - Paterna/C=ES
        Informational
            CA certificate identified
        Warning
            CA certificates should not include subject alternative names

    /CN=CAEDICOM Root/O=EDICOM/C=ES
        Informational
            CA certificate identified
        Warning
            CA certificates should include Digital Signature to allow signing OCSP responses
(In reply to Raúl Santisteban from comment #11)
> Actual URL checks provides different output. Can you please confirm If we
> should work on this new output?
> 
> 
> 
> Using certificate chain from 'https://rootcertificateprograms.edicom.es/'
> 
> Using certificate from local file 'CAEDICOMRoot'
> 
>     /CN=rootcertificateprograms.edicom.es
>         Warning
>             Extension should be critical for KeyUsage
>         Error
>             Unallowed key usage for RSA public key


Yes that's what I'm seeing now too. Please add a comment in this bug when the error (Unallowed key usage for RSA public key) is resolved. 
Note that the test is Powered by https://github.com/awslabs/certlint so if you find it is a problem in the test, then file an Issue in github, and add a comment in this bug to clarify.
Thanks.
Errors reported at tool
https://cert-checker.allizom.org/
Have been solved.
(In reply to Raúl Santisteban from comment #13)
> Errors reported at tool
> https://cert-checker.allizom.org/
> Have been solved.

Confirmed -- no errors.
Raúl, when do you expect to have the 2016 audit statements?
We are working on the audit process with the Third Party since first week of October. We've just asked for a estimated report delivery date. As soon as the Thir party answer I'll update with the answer.
Assignee: kwilson → awu
(In reply to Raúl Santisteban from comment #16)
> We are working on the audit process with the Third Party since first week of
> October. We've just asked for a estimated report delivery date. As soon as
> the Thir party answer I'll update with the answer.

Any update?
Webtrust letter
As the final report is being delayed, we asked to the audit company to provide some kind of bridge letter, attached as "EDICOM Certificate WebTrust.pdf"
Audit statement signed January 24, 2017. Still waiting for the official seal to be posted.
Attachment #8841805 - Attachment description: 2016-Edicom-Audit.pdf → 2016-Edicom-BR-Audit.pdf
Whiteboard: Ready for Public Discussion → [ca-ready-for-discussion 2016-01-25]
New webtrust Seal can be found at:
https://cert.webtrust.org/ViewSeal?id=2201
Raúl, Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.
Whiteboard: [ca-ready-for-discussion 2016-01-25] → [ca-ready-for-discussion 2016-01-25] - Need BR Self Assessment
Product: mozilla.org → NSS
Attached file BR Self Assesment
As requested, we attach BR Self Assesment ocording to current version of BR.
Whiteboard: [ca-ready-for-discussion 2016-01-25] - Need BR Self Assessment → [ca-ready-for-discussion 2016-01-25] - BR Self Assessment Received
Hi Raúl,

Thanks to provide BR Self Assessment, I am doing verification on each session currently.

One thing need your input first, please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.

Thank you so much!

Regards,
Aaron
(In reply to Raúl Santisteban from comment #25)
> Hello Aaron,
> The three URLs are:
> 
> https://rootcertificateprogramsrevoked.edicom.es
> https://rootcertificateprogramsexpired.edicom.es
> https://rootcertificateprograms.edicom.es/

Hi,

Thanks for your test websites!

The error message is shown once testing:
Forbidden Error: You don't have permission to access / on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Could you please check and fix?

Regards,
Aaron
Hello Aaron,
It's fixed. 

Regards,
Raúl.
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
I'm reviewing the data provided by this CA, and I find the following:

TSL CP:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Date: 29/06/15

CPS:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf
Date: 28/04/14

Are those the current versions of the CP/CPS?

If yes, how can they be compliant with a reasonably current version of the BRs?

Also, when do you expect to have new audit statements?
Whiteboard: [ca-ready-for-discussion 2016-01-25] - BR Self Assessment Received → [ca-verifying] - KW Comment #30 2018-02-13
Those were the links of the "current" version when creating this BUG. Obviosly they have been updated during this time.

Current version:
TSL CP:
https://acedicom.edicomgroup.com/eu/CAEDICOM01_CP_TLSCertificatesPolicy.pdf
Date 20/09/2017

CPS:
https://acedicom.edicomgroup.com/eu/CAEDICOM01_CPS_CertificationPracticeStatement.pdf
Date 14/06/2017

Regarding to the audit statements. I'vbe attached our last audit statement, which will be based from now on on new ETSI standards.
Next April is planned to start the new Audit process since last audit finished on June 2017.
(In reply to Raúl Santisteban from comment #31)
> Those were the links of the "current" version when creating this BUG.

I copied those links out of the attached BR Self Assessment document. 
So, which version of the documents were used for your BR Self Assessment?
Perhaps you should update your BR Self Assessment to compare your current CP/CPS with the current version of the BRs.


> Obviosly they have been updated during this time.
> 
> Current version:
> TSL CP:
> https://acedicom.edicomgroup.com/eu/CAEDICOM01_CP_TLSCertificatesPolicy.pdf
> Date 20/09/2017
> 
> CPS:
> https://acedicom.edicomgroup.com/eu/
> CAEDICOM01_CPS_CertificationPracticeStatement.pdf
> Date 14/06/2017

I will use those versions.


> 
> Regarding to the audit statements. I'vbe attached our last audit statement,

The attached audit statement is not sufficient:

1) It does not state the audit period, and so I cannot confirm that there is an unbroken sequence of audit periods. 
Note that the previous audit statement (https://cert.webtrust.org/SealFile?seal=2201&file=pdf) was for audit period October 31, 2015, to October 30, 2016.

2) It does not indicate enough detail regarding the type of audit
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#etsi

3) It does not contain all of the required information:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information
Whiteboard: [ca-verifying] - KW Comment #30 2018-02-13 → [ca-verifying] - KW Comment #32 2018-02-13
Can you please provide any status update?
Thanks,
The attached file shows the CA information that has been verified. Search in the document for the word "NEED" to see where further clarification is requested.

In particular:

1) Audit statements must also be provided in English, per:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

2) Recognized CAA domains must be listed in CP or CPS, per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS

3)  Need Complete Audit History, per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History
Also note:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
"Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually. Successive audits MUST be contiguous (no gaps)."
This root has validFrom: 5/21/2014
https://bugzilla.mozilla.org/attachment.cgi?id=8707470 - audit period 10/31/2014-10/30/2015
WebTrust CA - https://bugzilla.mozilla.org/attachment.cgi?id=8816896
WebTrust BR - https://bugzilla.mozilla.org/attachment.cgi?id=8841805 - 10/31/2015-10/30/2016
ETSI EN 319 411 - https://bugzilla.mozilla.org/attachment.cgi?id=9003448 - 6/19/2017 - 4/24/2018
***So it appears that we do not have audits for this root that cover the audit period 10/31/2016 - 6/18/2017. 

4) Fix Revoked and Expired test websites.
Currently they result in Error code: SSL_ERROR_BAD_CERT_DOMAIN
The certificate is only valid for rootcertificateprograms.edicom.es.
Test Website - Revoked: https://rootcertificateprogramsrevoked.edicom.es/ 	 
Test Website - Expired: https://rootcertificateprogramsexpired.edicom.es/

5) Resolve all lint testing errors
https://crt.sh/?caid=14975&opt=cablint,zlint,x509lint&minNotBefore=2014-05-21
https://crt.sh/?caid=15530&opt=cablint,zlint,x509lint&minNotBefore=2014-05-21
QA Contact: kwilson
Whiteboard: [ca-verifying] - KW Comment #32 2018-02-13 → [ca-verifying] - KW Comment #35 2018-10-18
Attached file PSC-2017/0001
English translation of the audit report.

New audit statement ETSI 319 411-2

New audit statement ETSI 319 411-1

You need to log in before you can comment on or make changes to this bug.