www.cert.fnmt.es certificates are not included in Mozilla products

[Alberto Salvia Novella]

Please add <www.cert.fnmt.es> (National Coin and Ding Factory of Spain) as a valid certification authority in the default Firefox installation.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: firefox 26.0+build2-0ubuntu0.13.10.2
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
Uname: Linux 3.11.0-14-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: es20490446e 2130 F.... pulseaudio
 /dev/snd/controlC1: es20490446e 2130 F.... pulseaudio
 /dev/snd/controlC0: es20490446e 2130 F.... pulseaudio
BuildID: 20131206145143
Channel: Unavailable
Date: Wed Jan 22 12:49:53 2014
Extensions: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
InstallationDate: Installed on 2013-05-21 (245 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
IpRoute:
 default via 192.168.2.1 dev eth0 proto static
 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.117 metric 1
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Locales: extensions.sqlite corrupt or missing
MarkForUpload: True
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=26.0/20131206145143 (In use)
RelatedPackageVersions:
 google-talkplugin 4.9.1.0-1
 icedtea-7-plugin 1.4-3ubuntu2
 totem-mozilla 3.8.2-0ubuntu1
 rhythmbox-mozilla 2.99.1-0ubuntu1
RfKill:

RunningIncompatibleAddons: False
SourcePackage: firefox
Themes: extensions.sqlite corrupt or missing
UpgradeStatus: Upgraded to saucy on 2013-10-18 (96 days ago)
WifiSyslog:

dmi.bios.date: 02/18/2008
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: MS-7358
dmi.board.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.board.version: Fab D
dmi.chassis.type: 3
dmi.chassis.vendor: OEM
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd02/18/2008:svnMEDIONPC:pnMS-7358:pvrOEM:rvnMICRO-STARINTERNATIONALCO.,LTD:rnMS-7358:rvrFabD:cvnOEM:ct3:cvrOEM:
dmi.product.name: MS-7358
dmi.product.version: OEM
dmi.sys.vendor: MEDIONPC

[Cristina-acedo (cristina-acedo)]

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: Firefox 2.0.0.14

CA Details
----------

CA Name: [ FNMT CLASE 2 CA ]

Website URL: [ http:// www.cert.fnmt.es ]

CA Summary:
  [ A one Paragraph Summary of your CA, including the following: Public Certification Authority (issues certificates to the general public). ]
  [ - General nature (e.g., commercial, government academic/research, nonprofit) Fábrica Nacional de Moneda y Timbre (FNMT) provides services to Spanishand established legaly on the territory citizens. Sector government. ]
  [ - Primary geographical area(s) served Geographical area: SPAIN ]
  [ - Number and type of subordinate CAs NO Subordinate CAs ]

Audit Type (WebTrust, ETSI etc.): [ ETSI 101 456 ]

Auditor: [ BSI Management Systems B.V ]

Auditor Website URL: [http:// www.bsi-global.com ]

Audit Document URL(s):
  [http://www.cert.fnmt.es/content/pages_std/docs/ETSI.pdf ]

URL of certificate hierarchy diagram (if available):
  [http:// ]

Certificate Details
-------------------
(To be completed once for each root certificate; note that we only
 include root certificates in the store, not intermediates.)

Certificate Name: [OU=FNMT CLASE 2 CA, O=FNMT, C=ES ]

Summary Paragraph:
  [ including the following: ]
  [ - End entity certificate issuance policy,
FNMT-RCM issues certificates to natural persons according to his Qualified Certificates Certification Policy (1.3.6.1.4.1.5734.3.5). This certificates bind a public key to a natural person, proving his identity. These certificates are issuing as Qualified Certificates based on Spanish Electronic Signature Law (59/2003) rules and ETSI TS 101 456 - “Policy requirements for certification authorities issuing qualified certificates” recommendations.

Certificates Profiles issued under to this FNMT-RCM Qualified Certificate Policy are issued according to ETSI TS 101 862 – “Qualified Certificate Profile”. ]
  [ i.e. what you plan to do with the root ]

Root certificate download URL (on CA website):
  [http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer]
  [alternatively, paste a copy of the certificate in "PEM" format ]

Version: [X509 v3]

Certificate SHA1 Fingerprint (in hexadecimal):
  [43 F9 81 10 D5 8A FD 48 22 52 31 80 DO 08 28 37 2F EF 9A 54]

MD5 Fingerprint: [ 25:9D:CF:5E:B3:25:9D:95:B9:3F:00:86:5F:47:94:3D]

Key size (for RSA, modulus length) in bits: [1024 ]

Serial number : [36:F1:1B:19]

Valid From (YYYY-MM-DD): [ 1999-03-18 ]
Valid To (YYYY-MM-DD): [ 2019-03-18 ]

CRL HTTP URL (if any):
  [ldap://ldap.cert.fnmt.es . Simple Authentication Services. Authorization required]

CRL issuing frequency for subordinate CA certificates: [ days ]
CRL issuing frequency for subordinate EE certificates: [ days ]

OCSP responder URL (if any):
  [http://apus.cert.fnmt.es/appsUsuario/ocsp/OcspResponder Signed request. Authorization required ]

Class: [Identity validat...

[Jan Darmochwal (jdarmochwal)]

adjusting product and component

[Cristina-acedo (cristina-acedo)]

Created attachment 322502
CA Details.doc

Cert Details

[Johnath (johnath)]

*** Bug 408008 has been marked as a duplicate of this bug. ***

[Hecker-hecker (hecker-hecker)]

Accepting bug. It will go into the queue with all the other requests, so we will not be processing it immediately.

[Willyaranda-1 (willyaranda-1)]

So, it won't be prepared for final release of Firefox 3, isn't it?

[Hecker-hecker (hecker-hecker)]

(In reply to comment #5)
> So, it won't be prepared for final release of Firefox 3, isn't it?

No. At this point Firefox 3.0 is almost ready to ship. (It will be officially released next Tuesday, June 17.) Our goal is to get more CAs approved for inclusion in future security update releases to Firefox 3.0, e.g., Firefox 3.0.1, 3.0.2, and so on.

[Jbecerra-mozilla (jbecerra-mozilla)]

Frank, is there a way to nominate this (or should it) for 3.0.x and 3.1? The certificate is necessary for some types of transactions, like buying train tickets, and having that option would help in Firefox adoption in Spain.

[Toni Hermoso Pulido (toniher)]

I support Juan, this and bug 295474 put Firefox in a competitive disadvantage in Spain compared to Internet Explorer:
http://support.microsoft.com/?scid=kb%3Ben-us%3B931125&x=16&y=15

[Unaiur-b (unaiur-b)]

It's also needed to pay taxes, to manage the driver license...

[Kwilson-r (kwilson-r)]

Accepting this bug, so I can do the information gathering/verification phase.

Kathleen

[Kwilson-r (kwilson-r)]

Created attachment 341484
Initial Information Gathering Document

Attached is the initial information gathering document, which summarizes the data that has been gathered and verified. Within the document I have highlighted in yellow the information that is still needed. I will summarize below.

1) This root is only 1024 bit. NIST recommend that all such roots be phased out by the end of 2010, yet this root expires in 2019. What is your current end-of-life plan with regard to this root? Is there a new root we should be reviewing for inclusion in Mozilla?

2) Is there a CRL for the end-entity certificates that is accessible via an external URL?
There is usually a statement in the CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 48 hours. If you have such a statement in your CP/CPS, would you please provide it in English?

3) Please confirm:
a) There are no subordinate CA’s issued by this root.
b) This root CA directly issues end entity certificates. End-entity certificates are signed using the private key of this root.

4) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ please translate the relevant text from the latest CP or CPS into English that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates:
a) for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
b) for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

5) Please identify if all SSL certs issued from this root are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber.
Are there any SSL certs issued from this root that are only DV? Eg the Organization attribute is not verified, only the domain name is verified?

6) I’m supposed to review the CP/CPS for potentially problematic practices,
as per http://wiki.mozilla.org/CA:Problematic_Practices. Would you please comment as to whether any of these are relevant?
If relevant, please provide further info.

7) Do you have an updated audit report?

Thanks,
Kathleen

[Cristina-acedo (cristina-acedo)]

 The answer of The FNMT about your questions are:

-- Comment #11 from Kathleen Wilson <email address hidden> 2008-10-02 12:22:49 PDT ---
Created an attachment (id=341484)
 --> (https://bugzilla.mozilla.org/attachment.cgi?id=341484)
Initial Information Gathering Document

Attached is the initial information gathering document, which summarizes the data that has been gathered and verified. Within the document I have highlighted in yellow the information that is still needed. I will summarizebelow.

1) This root is only 1024 bit. NIST recommend that all such roots be phased out by the end of 2010, yet this root expires in 2019. What is your current end-of-life plan with regard to this root? Is there a new root we should be reviewing for inclusion in Mozilla?

“We are planning to create a new Root CA for FNMT-RCM in 2009. Then we will send to Mozilla a formal request to include this certificate in Mozilla CA Certificate program”.

2) Is there a CRL for the end-entity certificates that is accessible via an external URL? There is usually a statement in the CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 48 hours. If you have such a statement in your CP/CPS, would you please provide it in English?

“YES. There are Certificate Revocation Lists (CRLs) for end-entity certificates published in a LDAP Directoy. The LDAP URL is: ldap.cert.fnmt.es. This is a simple authenticated service. In every end-entity certificate signed by our root CA there is a CRL Distribution Point pointing to the correct CRL. These CRLs are updated every 24 hours as well as every time a certificate is revoked”.

3) Please confirm:

a) There are no subordinate CA’s issued by this root. “Confirmed”.

b) This root CA directly issues end entity certificates. End-entity
certificates are signed using the private key of this root. “Confirmed”.

4) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/
please translate the relevant text from the latest CP or CPS into English that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates:

a) for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;

“In paragraph V.2 of FNMT-RCM’s Certification Practices Statement, Life cycle management of the certificates of components (we call Certificate of Components to SSL-enabled certificates, Code signing certificate and certificates issued for applications that needs authentication each other) are shown the necessary steps for obtaining an SSL Server Certificate. The first one is:

The entity interested in applying for a SSL Certificate, must maintain a previous contact with the Royal Spanish Mint (FNMT-RCM) in order to be provided with the information necessary for the issuance of the certificate requested, as well as the forms to be filled. The necessary documents are:

• Request Form for SSL Certificate f...

[Kwilson-r (kwilson-r)]

Thank you for the information.

>“The main purpose of certificates issued by FNMT-RCM Certification Authority
> is user identity authentication nor digitally sign and/or encryption email
> messages. The email is only used as contact method to send information to
>users”.
Then the requested trust bits should not include email (S/MIME). The requested trust bits should only be websites (SSL/TLS) and Code Signing. Do you agree?

In regards to the existing audit, I have submitted a request via the BSI website to verify the authenticity of the audit statement as per Mozilla policy. Once the old audit is verified, I think we can proceed with evaluation of this request.

The existing audit has expired, so an updated audit will probably be needed before final inclusion.

>Long-Lived Domain-Validated SSL certs
>“DV certificates issued by FNMT-RCM CA has four year of validity period. Do
>you mind that four years is very large? In any case, we only issue DV
>certificates to very contrasted legal entities (public or private)”.
I am not sure what “contrasted legal entities” means.
This is only a concern for SSL certs in which the identity or organization of the owner of the certificate has not been verified. If you issue 4-year certs in which only the domain name has been verified, then the certs are subject to the issue described in
https://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates

>“The CRLs issued by FNMT-RCM CA have the CRL Issuing Distribution Point
>extension flagged as critical as X509 recommends.”
This is problematic because Firefox will return the error code ffffe095 when attempting to load a CRL with the critical CIDP. It is highly recommended that you don’t make this extension critical until this has been resolved in Firefox, which is still TBD.

[Nukeador-d (nukeador-d)]

(In reply to comment #13)
> In regards to the existing audit, I have submitted a request via the BSI
> website to verify the authenticity of the audit statement as per Mozilla
> policy. Once the old audit is verified, I think we can proceed with evaluation
> of this request.

Do we have an answer about this?

> This is problematic because Firefox will return the error code ffffe095 when
> attempting to load a CRL with the critical CIDP. It is highly recommended that
> you don’t make this extension critical until this has been resolved in Firefox,
> which is still TBD.

Is this issue solved now or for Fx 3.5?

[Julen Ruiz Aizpuru (julen)]

Please, consider this bug affects at least es-ES, ca, and eu localizations of Firefox. What are we supposed to tell our users when a single response on bugs like this take months? Are we really taking care of the user experience?

[Eddy-nigg (eddy-nigg)]

Julen, please note that Kathleen has posted additional questions to this bug in comment 13. It is upon the CA to reply here.

[Kwilson-r (kwilson-r)]

I have been waiting for a response to my previous post. Since that was so long ago, I will summarize here what information I am looking for now.

1) The “FNMT Clase 2 CA” is 1024 bit. FNMT will create a replacement root in 2009. Has your new root been created and audited? If so, I recommend including that root in this request.

2) Can you provide a URL that can be used for downloading the CRL instead of ldap?
The information about CIDP has been updated, please see
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

3) This root directly issues end-entity certificates. If the new root has been created, is it offline, with sub-CAs?

4) “The main purpose of certificates issued by FNMT-RCM Certification Authority is user identity authentication nor digitally sign and/or encryption email messages. The email is only used as contact method to send information to users”.
Then the requested trust bits should not include email (S/MIME). The requested trust bits should only be websites (SSL/TLS) and Code Signing, not email. Do you agree?

5) I did not ever receive a reply from BSI in regards to the audit report. However, it’ll be best to get and confirm the 2009 audit report instead. My understanding was that the audit was planned for early this year. Has it happened?

6) “DV certificates issued by FNMT-RCM CA has four year of validity period. Do you mind that four years is very large? In any case, we only issue DV certificates to very contrasted legal entities (public or private)”.
According to paragraph V.2 of the CPS, is it accurate to say that all SSL certificates are identity or organizationally verified? Or do you ever issue SSL certs where only the domain name had been verified, and the identity or organization is not verified?

[Rpmdisguise-otros (rpmdisguise-otros)]

Pinging FNMT staff, since you are the one to provide the requested data. Moreover, more public administration sites are going into production with a FNMT certificate, like the Madrid Public Health Service web site for medical apointments self-service:

https://www.citaprevia.sanidadmadrid.org/

Firefox users will have access denied to the page if FNMT is not trusted as it is now because of this bug not moving further, and both Mozilla and the FNMT will get bad press.

This bug has been opened for more than a year now, following another previous one, and the delays caused by both sides have been these to date:

Mozilla
-------

26/05/2008 (#5) --> 12/06/2008 (#6): 17 days
12/06/2008 (#6) --> 02/10/2008 (#10): 30 + 31 + 31 + 21 = 114 days

Mozilla total: 131 days

FNMT
----

02/10/2008 (#11) --> 01/12/2008 (#12): 31 + 29 = 60 days
02/12/2008 (#13) --> 12/03/2009 (#17): 31 + 31 + 28 + 10 = 100 days
12/03/2009 (#13) --> Today: 31 + 30 + 19 = 80 days

FNMT total: 240 days

Grand total: 371 days

Even if 131 days is proof that Mozilla needs reviewing his process to get CAs accepted, the 240 days delay by FNMT, 180 days without a single commment, is completely unacceptable.

We, as the Spanish Mozilla Community, must and will take every step at hand to make clear to Spanish users what is the reason why Firefox users can't access in a secure way to government sites using FNMT certificates.

[Lucianosan-d (lucianosan-d)]

Hello Kathleen

Include the CA Root certificate for FNMT-RCM CA Spanih on next Mozilla update it easy.
Only thing is get certificate from http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
and include it on next update, for example 3.0.11
Can be it possible please ?
It would be pleasure for all Spanish Mozilla Community

Sorry for my bad english
Best Regards
Luciano

[Kwilson-r (kwilson-r)]

Before a root can be added to Mozilla, the process described at
https://wiki.mozilla.org/CA:How_to_apply
must be completed.

This request is currently in the Information Gathering and Verification phase as described at
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

In order to proceed, an official representative of FNMT must respond to the items listed in Comment #17.

After the Information Gathering and Verification phase is completed, the request then has to go through the public discussion phase, which is described at https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Perhaps you can contact FNMT to encourage them to respond?

[Nukeador-d (nukeador-d)]

Luciano, please let's keep the discussion at the dev.crypto mailing list:

http://groups.google.es/group/mozilla.dev.tech.crypto/browse_thread/thread/da33d24030fe5e6f/9314b4ae9cbebb09

This way we will keep the bug clean just for comment about the process.

Kethleen, I've been personally in contact with Carolina from FNMT during the whole process to help them, but I haven't got any reply from her for too long (I tried several times), and I got the return receipt back, so I know they got my emails.

Since this is a BIG marketing issue in Spain, as Ricardo said before, we will inform from the community about the process and who should move next.

[Juan Jose Pablos (cheche)]

ping. Please now that the holidays season has finished, please move on this issue.

[Alberto Salvia Novella (es20490446e)]

Created attachment 8363598
AC Raíz FNMT-RCM.crt

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131206145143

Steps to reproduce:

1. Go to <https://www.sede.fnmt.gob.es/certificados>.
2. Tried to renew my certificate from the National Coin and Ding Factory of Spain (FNMT).

Actual results:

When you try to renovate certificates; you are directed to a secure page, where Firefox says the connection is unreliable because it doesn't recognize FNMT - RCM as a valid certification authority.

Expected results:

To be able to renovate certificates without having to add a security exception.

[Alberto Salvia Novella (es20490446e)]

Since there's a missing certificate from the attachment, ignore it.

Certificates can be found at <http://preview.tinyurl.com/nwxgpko>.

[Alberto Salvia Novella (es20490446e)]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131206145143

Steps to reproduce:

Sent a message signed with a certificate from the National Coin and Ding Factory of Spain (FNMT)

Actual results:

Since FNMT is not a certification authority carried in the default Thunderbird installation, sent certificate is seeing as invalid to all the recipients.

Expected results:

Certificate seeing as valid to all the recipients.

[Alberto Salvia Novella (es20490446e)]

Certificates can be found at <http://preview.tinyurl.com/nwxgpko>.

[Alberto Salvia Novella (es20490446e)]

Also affects Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=962527

[Alberto Salvia Novella (es20490446e)]

Also affects Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=962536

[Alberto Salvia Novella (es20490446e)]

Certificates can be found at <http://preview.tinyurl.com/nwxgpko>.

[Alberto Salvia Novella (es20490446e)]

Created attachment 8363633
Certificates.tar.gz

[Alberto Salvia Novella (es20490446e)]

Created attachment 8363634
Certificates.tar.gz

[Alberto Salvia Novella (es20490446e)]

Created attachment 8363635
Certificates.tar.gz

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Certificates.tar.gz" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Cviecco (cviecco)]

Alberto, including a new trust anchor to our trust store is a process to ensue the security of all our users. If you are part of FMNT (Fabrica Nacional de Moneda y Timbre) please read http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ and after following the documented steps ask for inclusion into our root program.

[Alberto Salvia Novella (es20490446e)]

I'm not part of FNMT.

El 26/02/14 21:58, Cviecco escribió:
> Alberto, including a new trust anchor to our trust store is a process to
> ensue the security of all our users. If you are part of FMNT (Fabrica
> Nacional de Moneda y Timbre) please read <http://www.mozilla.org/en-
> US/about/governance/policies/security-group/certs/policy/> and after
> following the documented steps ask for inclusion into our root program.
>

[Alberto Salvia Novella (es20490446e)]

I don't belong to FNMT, although I noticed them about this bug. They told me they're following the mentioned steps.

Thank you.

[Kwilson-r (kwilson-r)]

The FNMT-RCM root certificate is not yet included in NSS. That request is Bug #435736.

There are two ways a user can work around this problem...

1) Add an exception as described here:
https://support.mozilla.org/en-US/kb/connection-untrusted-error-message#w_bypassing-the-warning

or

2) Manually import and trust the root certificate as described here:
https://wiki.mozilla.org/CA:UserCertDB#Importing_a_Root_Certificate

*** This bug has been marked as a duplicate of bug 435736 ***

[Consultingwebtrust (consultingwebtrust)]

(In reply to Kathleen Wilson from comment #137)
> Thank you for the clarification.
>
> Here's the current status of this request...
>
> Needed to complete the Information Verification phase:
> https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
>
> 1) Audit statement (e.g. WebTrust for CA or ETSI 102 042) that covers SSL
> and Code Signing certs
>
> 2) BR Commitment to Comply in CP/CPS

Dear Kathleen,

Regarding the audit statement, we strongly believe that there are major overlaps between the “WebTrust Principles and Criteria for Certification Authorities Version 2.0” and the “WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2.0” and such issue should be clarified in the Mozilla CA Certificate Policy. We understand that under the Mozilla’s own criteria, both document's requirements must be satisfied. However, we think this is not the most efficient way to handle it because of the extra cost and time that CA's management need to budget to engage duplicate reporting of the same controls. We kindly ask you for some clarification of this situation to the industry, CPA Canada and users, because we did not find any reference about it and many of us have serious doubts in that respect.

Having said this, we have developed a compliance matrix (CA + SSL BR) for this client and indeed all the requirements have been satisfied and we have evidences about this assertion. Please let us know how to go ahead.

We remain at your disposal for any further clarification concerning this topic.

Best regards.

[Kwilson-r (kwilson-r)]

(In reply to Antonio from comment #138)
> Having said this, we have developed a compliance matrix (CA + SSL BR) for
> this client and indeed all the requirements have been satisfied and we have
> evidences about this assertion. Please let us know how to go ahead.

Please see item #2 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

[Rafamdn (rafamdn)]

Created attachment 8565442
General CPS applicable to all FNMT's CAs (February 2015)

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #139)
> Please see item #2 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices

Hi Kathleen,

on this issue, item #2 says:

"If you provide the information yourself (e.g., it is hosted on your own web site), please provide us with contact information for the auditor (or other third party)."

So, if we publish at our web site a self-statement and we also provide the auditor's contact information, could be enough to meet Mozilla's requirements?

[Kwilson-r (kwilson-r)]

(In reply to Rafa from comment #141)
> (In reply to Kathleen Wilson from comment #139)
> > Please see item #2 of
> > https://wiki.mozilla.org/CA:
> > Information_checklist#Verification_Policies_and_Practices
>
> Hi Kathleen,
>
> on this issue, item #2 says:
>
> "If you provide the information yourself (e.g., it is hosted on your own web
> site), please provide us with contact information for the auditor (or other
> third party)."

That is referring to the auditor's statement. If the auditor's statement is published or provided by the CA, then I do a separate process to contact the auditor to confirm the authenticity of the auditor's statement.

>
> So, if we publish at our web site a self-statement and we also provide the
> auditor's contact information, could be enough to meet Mozilla's
> requirements?

No. A self-statement does not help.
We need audit statement(s) that meet the requirements of sections 11 through 14 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #142)

> No. A self-statement does not help.
> We need audit statement(s) that meet the requirements of sections 11 through
> 14 of
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy/inclusion/

Hi Kathleen.

Regarding this question, we have published at our website an Audit Report from auditor. Within this document you can see contact information for the auditor.

It can be downloaded from:
- https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf (english)
- https://www.cert.fnmt.es/documents/11601/4379265/auditReport_es.pdf (spanish)

I think there are no more pending questions.

[Kwilson-r (kwilson-r)]

Created attachment 8607639
435736-CAInformation.pdf

The Root Cert URL, http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt, now points to the SHA-256 root, so I updated the technical details about the root cert in SalesForce. Please confirm that the information in the attached document is correct.

Also, due to the frequency of OCSP errors being found during the discussion phase we have added a check for CAs to address these issues before their request goes to the discussion phase, using the http://certificate.revocationcheck.com/ website.

When I entered https://www.sede.fnmt.gob.es/certificados into the revocation checker the following OCSP errors were listed. Please comment in this bug when these have been resolved.

http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
- bad signature on embedded certificate
- OCSP response expired
- NextUpdate happens before the date in the Expires cache header
- Error parsing OCSP response

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #144)
> >
> When I entered https://www.sede.fnmt.gob.es/certificados into the revocation
> checker the following OCSP errors were listed. Please comment in this bug
> when these have been resolved.

Two days ago we have updated our OCSP Server configuration and we have solved OCSP related bugs.

[Kwilson-r (kwilson-r)]

I just tried it again: http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
returns: Error parsing OCSP response: asn1: structure error: tags don't match (16 vs {class:0 tag:28 length:72 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 set:false omitEmpty:false} responseASN1 @2

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #146)
> I just tried it again:
> http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
> returns: Error parsing OCSP response: asn1: structure error: tags don't
> match (16 vs {class:0 tag:28 length:72 isCompound:true}) {optional:false
> explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0
> set:false omitEmpty:false} responseASN1 @2

This problem it's not an OCSP Server problem. As you can see, POST request are resolved correctly.

The type GET requests with certain special characters in the base 64 encoding (+, /, ..) with special meaning in URIs must be encoded first with "URL encoding" before sending, according to RFC 2560, and RFC 6960 A.1.1 point point A.1. However, they are not doing, as seen in the logs of our web server.

Specifically, the parsing error occurs because when treating the wrong GET request our OCSP Server sends a redirect to a welcome page, which logically cause the OCSP response parsing error.

You can see the same behaviour if you check other SSL certificates issued by other root CAs inluded in Mozilla root CA Program.

[Rafamdn (rafamdn)]

Analyzing the raw data (by clicking in "Raw data" button at the top right of page), we can see that the OCSP GET Request for subordinate CA contains special characters (two '+' symbols) that should be encoded properly (URL encoding).

I attach copy&paste raw data of OCSP request (PEM encoded):

-----BEGIN OCSP REQUEST-----
MEIwQDA+MDwwOjAJBgUrDgMCGgUABBS634rj9+tQjJTBuuMefNw6cT1ENwQUFBHi
tSu5jJitaNMxVEDkWF8DG30CAQI=
-----END OCSP REQUEST-----

[Kwilson-r (kwilson-r)]

Created attachment 8644041
435736-CAInformation-Final.pdf

[Kwilson-r (kwilson-r)]

I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

In the meantime, please clarify your audit plans for 2015.

My current notes have...
WebTrust CA Audit (5/4/2014): https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf
WebTrust BR Audit (12/3/2014): https://cert.webtrust.org/SealFile?seal=1784&file=pdf

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #150)
> I will try to start the discussion soon.
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
>
> In the meantime, please clarify your audit plans for 2015.
>
> My current notes have...
> WebTrust CA Audit (5/4/2014):
> https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf
> WebTrust BR Audit (12/3/2014):
> https://cert.webtrust.org/SealFile?seal=1784&file=pdf

We will start audit tasks next october. We hope to have renewed seal on november 2015.

In addition, we have got the ETSI TS 101 456 V1.4.3 seal this August 2015 (http://www.cert.fnmt.es/documents/11601/5161307/ETSI_101_456.pdf).

The audit tasks for renewal of ETSI seal will be done on 2T of 2016 so we almost will be on a continous audit process.

[Kwilson-r (kwilson-r)]

Created attachment 8677034
435736-CAInformation-Final.pdf

[Kwilson-r (kwilson-r)]

I am now opening the first public discussion period for this request from FNMT to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.

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 “FNMT Root Inclusion Request”.

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

A representative of FNMT must promptly respond directly in the discussion thread to all questions that are posted.

[Nukeador-u (nukeador-u)]

Rafa, for reference, this is the thread to follow for questions:

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7wIZmwp4qGQ

Cheers.

[Kwilson-r (kwilson-r)]

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://www.sede.fnmt.gob.es/certificados'

Using certificate from local file 'ACRAIZFNMT.cert'

    /C=ES/O=FNMT-RCM/OU=sede electr\xC3\xB3nica/OU=SEDE ELECTRONICA FNMT-RCM/serialNumber=Q2826004J/CN=www.sede.fnmt.gob.es
        Notice
            O could be encoded as PrintableString
            OU could be encoded as PrintableString
            CN could be encoded as PrintableString
        Informational
            No checks for DirectoryName
            TLS Server certificate identified
        Warning
            Unable to check unicode normalization of certificate policy explicit text
        Error
            BR certificates with organizationName must include either localityName or stateOrProvinceName
            BR certificates may not contain DirName type alternative names

...

    /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM
        Notice
            O could be encoded as PrintableString
            OU could be encoded as PrintableString
        Informational
            CA certificate identified
        Error
            CA certificates must include commonName in subject
~~

Please add a comment in this bug when the errors have been resolved.

[Kwilson-r (kwilson-r)]

(In reply to Kathleen Wilson from comment #155)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

[Rafamdn (rafamdn)]

(In reply to Kathleen Wilson from comment #155)
> Error
> CA certificates must include commonName in subject
> ~~

We have a question regarding this Error.

In "CA-Browser-Forum-BR-1.3.2" doc, at section 7.2.1 it's said:

"The Certificate Subject MUST contain the following:
‐ countryName (OID 2.5.4.6). This field MUST contain the two‐letter ISO 3166‐1 country code for the
country in which the CA’s place of business is located.
‐ organizationName (OID 2.5.4.10). This field MUST contain the name (or abbreviation thereof),
trademark, or other meaningful identifier for the CA, provided that they accurately identify the CA.
The field MUST NOT contain exclusively a generic designation such as “Root 1”."

Nothing is said about any commonName in subject nor that that field is required.

[Rafamdn (rafamdn)]

Also, regarding the error "BR certificates must not contain directoryName type alternative name", it has been discussed yet at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7wIZmwp4qGQ.

As it was commented, our certificates are compliant with this requirement as we set the Domain Name (there is at least a DNSName). Also, in order to comply with all applicable law related to eGovernment and identification of eOffices, administrative ID info must be set at SAN extension. As stating at section 8 of BRs we are oblied to do so.

Even if you look at CABForum EV Guidelines (9.2.2), about Subject Alternative Name it is just said:
 "This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates.

You'll agree that this is a less restrictive assertion (and it's about EV certificates wich are more sensitive and requirements are harder) and it should be taken into account.

I suggest to change the error message to a warning in order to allow CAs to explain its especial circumstances.

[Dkeeler (dkeeler)]

(In reply to Rafa from comment #157)
> (In reply to Kathleen Wilson from comment #155)
> > Error
> > CA certificates must include commonName in subject
> > ~~
>
> We have a question regarding this Error.
...
> Nothing is said about any commonName in subject nor that that field is
> required.

Yes - we've confirmed that it isn't required for inclusion in Mozilla's program. I updated cert-checker to make this a notice rather than an error.

[Kwilson-r (kwilson-r)]

(In reply to Rafa from comment #158)
> Also, regarding the error "BR certificates must not contain directoryName
> type alternative name", it has been discussed yet at
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/
> 7wIZmwp4qGQ.
>

I started a discussion about these certlint tests in mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ
Issues that require further discussion should be moved there, so that others may contribute to the discussion/decision, I will be able to refer people to the decisions later, and the results will benefit everyone who is now required to run these tests.

I moved the discussion about
 Error
   BR certificates with organizationName must include either localityName or stateOrProvinceName
   BR certificates may not contain DirName type alternative names

to mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/fQm2VYb4AAAJ

[Kwilson-r (kwilson-r)]

Created attachment 8766583
Webtrust Report - BR SSL FNMT-RCM.pdf

[Kwilson-r (kwilson-r)]

Created attachment 8766584
Webtrust Report - Principles and Criteria FNMT-RCM.pdf

[Rafamdn (rafamdn)]

Created attachment 8775143
2016 ETSI Seal

[Rafamdn (rafamdn)]

Created attachment 8775145
2016 Browser audit Attestation

[Kwilson-r (kwilson-r)]

Here's a summary of the audit information that has been provided, and the intermediate certs that have been revoked (to be added to OneCRL).

WebTrust CA audit statement from PricewaterhouseCoopers dated May 18, 2016
https://bug435736.bmoattachments.org/attachment.cgi?id=8766584
Root certificates covered: FNMT-RCM Root CA
Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos”

WebTrust BR audit statement from PricewaterhouseCoopers dated May 18, 2016
https://bug435736.bmoattachments.org/attachment.cgi?id=8766583
Root certificates covered: FNMT-RCM Root CA
Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos”

ETSI TS 101 456 audit certificate from TUVIT dated 2016-06-21
https://bug435736.bmoattachments.org/attachment.cgi?id=8775143
Root certificates covered: OU=AC RAIZ FNMT-RCM
Intermediate certificates covered:
CN = AC Administracion Publica
CN = AC FNMT Usarios
CN = AC Representacion

Audit Attestation by TUVIT
https://bug435736.bmoattachments.org/attachment.cgi?id=8775145
Root certificates covered: OU=AC RAIZ FNMT-RCM
“The assessment covered the period from May 6, 2015 until May 4 2016. It was verified that the CA’s “AC FNMT Usuarios” and “AC Representacion” don’t issue SSL/TSL certificates”

Subordinate CAs revoked and to be added to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1263949
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 8A:8E:8D:48:BC:44:F7:9D:80:67:F8:0F:14:1E:C5:A0:A9:97:99:D5
  sha256 hash: FD:01:90:1F:E7:C4:F5:14:D6:36:DF:64:C0:74:4A:A4:02:9D:B9:16:A3:6F:28:47:4C:84:0E:68:07:93:6A:1E
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 24:F1:1E:3F:73:DE:D8:92:D4:F0:E3:3B:8A:8F:5A:A5:21:88:A3:C2
  sha256 hash: 0D:4C:32:4B:B0:B0:08:F4:5E:EC:73:8B:8E:51:B3:7D:25:0F:76:F0:5F:6A:0C:30:13:66:10:20:A2:07:25:65
subject: C=ES, O=FNMT-RCM, CN=ISA CA
  sha1 hash: 5E:7F:EE:F9:4C:1F:C5:C6:A2:34:46:8C:89:6B:5D:BA:CA:05:97:69
  sha256 hash: 05:2B:EB:BD:CD:5C:84:7B:FA:0F:6F:B0:EA:22:46:B5:5B:A9:EE:55:E0:2A:2D:48:0B:87:FC:2F:34:2C:84:43
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 35:EC:75:F8:81:25:03:39:D1:52:5F:EB:0E:23:44:BC:DE:7A:5A:5C
  sha256 hash: C0:81:EA:C7:B9:80:7B:70:BD:DC:AC:13:1F:07:B6:67:E4:D9:DE:7F:56:8C:43:BA:01:11:13:A1:E7:53:48:99
subject: C=ES, O=FNMT-RCM, CN=EU ISA CA
  sha1 hash: 7C:C6:1C:DE:A5:7E:02:6E:2D:A5:C3:C7:66:01:39:A6:6E:AC:80:DE
  sha256 hash: BF:1C:7E:BA:A0:AC:08:9C:16:DD:C7:EA:03:88:D8:3F:47:21:DD:86:2F:E8:71:5E:19:BA:07:82:AE:D1:46:FE
subject: C=ES, O=FNMT-RCM, CN=EU ISA CA
  sha1 hash: B5:CF:1B:22:8A:1A:A3:93:84:3A:C8:02:AB:F9:58:A1:A5:5F:DF:ED
  sha256 hash: 69:9C:E8:E2:05:65:1E:F4:8B:03:85:33:15:AE:48:2C:A0:4B:F2:B3:E2:D9:B5:A5:EF:08:E8:CB:13:86:9B:B6

[Kwilson-r (kwilson-r)]

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 Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) 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].
FNMT appears to provide a service relevant to Mozilla users. It provides services to Spain as a national CA.

Root Certificate Name: AC RAIZ FNMT-RCM
O From Issuer Field: FNMT-RCM
Trust Bits: Websites
EV Policy OID(s): Not EV
Root Certificate Download URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

CA Document Repository: https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
CP: https://www.sede.fnmt.gob.es/documents/11614/67070/dpc_componentes_english.pdf/
CPS: https://www.sede.fnmt.gob.es/documents/11614/137578/dpc_english.pdf/
Updated CPS attached to bug February 2015:
https://bug435736.bugzilla.mozilla.org/attachment.cgi?id=8565442

Certificate Revocation
OCSP URL(s):
http://ocspape.cert.fnmt.es/ocspape/OcspResponder
http://ocspap.cert.fnmt.es/ocspap/OcspResponder

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

* SSL Verification Procedures: According to section 6.1.3 of dpc_componentes_english.pdf, if the Certificate is associated with one or more Internet domains, the Registry Office will check, on the authorized domain registrars' databases, that the title holder of the domain and the Certificate Subscriber match, and will keep proof of the inquiry.

* EV SSL Verification Procedures: Not requesting EV treatment
* Email Verification Procedures: Not requesting Email trust bit
* Code Signing Subscriber Verification Procedure: Not requesting Code Signing trust bit

Inclusion Policy Sections 11-14 [Audit].
See Comment #165 for details about FNMT's audits.

Inclusion Policy Section 18 [Certificate Hierarchy]
There are internally-operated subCAs in this CA hierarchy, and there is no plan to allow for externally-operated subCAs. The internally-operated subCAs are as follows:
+ AC Administración Pública
     - Issues: SSL certs, QCP certs
     - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456
+ AC Componentes Informáticos
     - Issues: SSL certs
     - Audits: WebTrust for CAs, WebTrust SSL BRs
+ AC FNMT Usuarios
     - Issues: issues QCP certs, not restricted by EKU extension
     - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of non-existence of SSL certs
+ ISA CA - revoked, being added to OneCRL via Bug #1263949
+ AC APE - revoked, being added to OneCRL via Bug #1263949

Based on this assessment I intend to approve this request from FNMT to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.

[Kwilson-r (kwilson-r)]

As per the summary in Comment #166, and on behalf of Mozilla I approve this request from Fábrica Nacional de Moneda y Timbre (FNMT) to included the following root certificate:

** “AC RAIZ FNMT-RCM” (websites)

I will file the NSS bug for the approved change.

[Kwilson-r (kwilson-r)]

I have filed bug #1299951 against NSS for the actual change.

[Ryan-sleevi (ryan-sleevi)]

Per Comment #166:

The following is an example of a certificate that FNMT has misissued: https://crt.sh/?id=13283681 (SHA-256 hash e5757f28a974675950fd2f76b7633811c86f60b6528644ec1dc81a7465980a7f )

.gc is not an IANA-delegated ccTLD or ICANN-contracted gTLD, therefore, it is an intranet domain.

Per the Baseline Requirements:
the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates

This certificate was issued on Feb 9, 2016 with an expiration of Feb 9, 2018

[Rafamdn (rafamdn)]

The (old) CA that issued that certificate was remove from this inclusion request -> Comment #98

[Hualgom (hualgom)]

If this issue is resolved, then why is this still happening:
https://www.ssllabs.com/ssltest/analyze.html?d=correo.uhu.es

FNMT-RCM is already in:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.28.1_release_notes

The following CA certificates were Added
OU = AC RAIZ FNMT-RCM
SHA-256 Fingerprint: EB:C5:57:0C:29:01:8C:4D:67:B1:AA:12:7B:AF:12:F7:03:B4:61:1E:BC:17:B7:DA:B5:57:38:94:17:9B:93:FA

[Cosme Domínguez (cosme)]

(In reply to Alex from comment #171)
> If this issue is resolved, then why is this still happening:
> https://www.ssllabs.com/ssltest/analyze.html?d=correo.uhu.es
>

That site (https://correo.uhu.es) doesn't provide the full certificate chain. In other words, it doesn't provide the intermediary CA (AC Componentes Informáticos) used to issued his certificate.

As said by cor-el [1]:

"Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage. If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet."

You can check it by visiting this web:

https://www.edu.xunta.es/webmail/

before https://correo.uhu.es. Then you shouldn't see any unknown issuer warning.

About ssllabs.com/ssltest, it seems that they don't follow Firefox release schedule. [2]

[1] https://support.mozilla.org/es/questions/1021610#answer-632157
[2] https://community.qualys.com/thread/15629#comment-36145

[Tahariel-a (tahariel-a)]

The first problem, is that "AC Componentes Informáticos" use SHA1 signing algo, and Mozilla dropped since the beginning of this year, i dont know if was dropped in all channels or only on dev/nightly for now.

About Cert Chain, yes, correo.uhu.es (My old campus, amazing)server is bugged.

[Cosme Domínguez (cosme)]

(In reply to Theliel from comment #173)
> The first problem, is that "AC Componentes Informáticos" use SHA1 signing
> algo, and Mozilla dropped since the beginning of this year, i dont know if
> was dropped in all channels or only on dev/nightly for now.

Here with Firefox 51 works, so it seems that Firefox still allows SHA1 signing in the cert chain.

But, as you said, it's going to be a problem in a short time. [1]

[1] https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/

[Víctor (victormontolioferrer)]

As noted in the Release Notes of Firefox 52.0 [1], released March 7,
'Display (but allow users to override) an “Untrusted Connection” error when encountering SHA-1 certificates that chain up to a root certificate included in Mozilla’s CA Certificate Program.'

So, it applies to all certs that have "AC Componentes Informáticos" in the cert chain.

Untrusted Connection error with code: "SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED" is expected on all websites that have certs like https://www.edu.xunta.es/webmail/ (referenced before). Users may feel they have the same error like before Firefox 51.0.

The only and unique version of Firefox where certs like this one works, is 51.0, released January 24, which was updated to NSS 3.28.1.

[1] https://www.mozilla.org/en-US/firefox/52.0/releasenotes/

(Websites that have certs with "AC Administración Pública" in the cert chain ARE NOT impacted, as "AC Administración Pública" is signed with SHA-256. Example: https://sede.educacion.gob.es/ )

[Jmtcarballo-9 (jmtcarballo-9)]

Created attachment 8898937
Audit_Attestation_FNMT_2017.pdf

[Rafamdn (rafamdn)]

Created attachment 9057798
Audit_Attestation_FNMT_2019.pdf