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

Bug #1271513 reported by Alberto Salvia Novella on 2014-01-22
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Wishlist
Mozilla Thunderbird
Fix Released
Wishlist
firefox (Ubuntu)
Wishlist
Unassigned
thunderbird (Ubuntu)
Wishlist
Unassigned

Bug Description

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

Download full text (3.5 KiB)

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...

Read more...

adjusting product and component

Created attachment 322502
CA Details.doc

Cert Details

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

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

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

(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.

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.

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

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

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

Kathleen

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

Download full text (7.5 KiB)

 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...

Read more...

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.

(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?

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?

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

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?

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.

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

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?

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.

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

80 comments hidden view all 160 comments

(In reply to Brian Smith (:bsmith) from comment #102)
> tef asked us to do this and so this should probably be tef+. I can't figure
> out how to set that flag.

Note: we won't be able to get this done today so it should be blocking-basecamp- but I nom'd it so that somebody with power and authority can set the tef+ flag, which doesn't appear for me in bugzilla.

(In reply to Brian Smith (:bsmith) from comment #102)
> tef asked us to do this and so this should probably be tef+. I can't figure
> out how to set that flag.

Okay, done.

FNMT still needs to provide their updated CPS and audit statements, and we still need to have their request discussed in m.d.s.policy.

What is the deadline for blocking-b2g?

Kathleen

(In reply to Brian Smith (:bsmith) from comment #99)
> (In reply to Kathleen Wilson from comment #98)
> > (In reply to Rafa from comment #97)
> > > Regarding #3, I agree with you. This inclusion request is only for de new
> > > "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?

I answer your questions:

> Before you modify the inclusion request:
>
> 1. How many websites are chaining to the old root? How many are chaining to
> the new root? If there are many websites chaining to the old root then we
> should find a way to get the old root working.

Currently most of SSL certificates issued by FNMT are chaining to the old root. We expect this change during 2013.

> 2. Does the new "AC RAIZ FNMT-RCM" root cross-sign the older root? Would it
> make sense to create such a cross-signing so that we could include only the
> "AC RAIZ FNMT-RCM" root? Would that be sufficient to address the concern
> that the old root issued EE certificates directly?

No, new root is not going to cross-sign the older root.

> 3. Is FNMT still issuing certificates from the Class 2 certificate, or is
> FNMT currently only issuing new certificates from the "AC RAIZ FNMT-RCM"
> root?

Currently we issue certificates with the "old root". We plan to stop issuing SSL certificates with old root by mid-year or 3Q 2013

> The fact that https://www.cert.fnmt.es/ itself uses a certificate that was
> directly issued by the Class 2 certificate, combined with the fact that
> Chrome and IE trust that certificate, indicates to me that adding only the
> "AC RAIZ FNMT-RCM" certificate is not going to solve the problems we are
> trying to solve.
>
> The process for revoking trust in a sub-CA certificate is the same process
> we would use for revoking trust in a root CA certificate. Consequently, I am
> not sure there's much practical benefit in avoiding adding the Class 2
> certificate on that basis.
>
> Another question: How common is it for FNMT to issue certificates for
> domains outside of *.es? Would it be reasonable to limit the trust of FNMT
> to .es domains, at least in the short-term?

Most of SSL certificates we issue are for .es domains. In fact most of them are issued to Public Administration entities or associated organizations.

So it would be reasonable solution limit trust to .es domains.

(In reply to Kathleen Wilson from comment #105)
> What is the deadline for blocking-b2g?

I'd say ASAP but that won't help :) How about we say next Friday, January 25?

How are things going here?

Still needed (from comment #101):
> As per Comment #100, please update this bug with URLs to the new CPS and
> audit statement when available.
>
> Please also add a comment to this bug to provide your response to the action
> items listed in the CA Communication that was sent today, and is available
> here:
> https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

New version of our CPS is pending of final approval. As soon as it's released I will update it in the thread.

In addition, we are working in response to the last "CA Comunication". I hope it'll be ready soon.

De-noming because it looks like it will be a while and it looks like I was mistaken in considering it a blocker when I nominated it. I should have marked it tracking-b2g instead, but AFAICT I cannot do that in the NSS product.

(In reply to Brian Smith (:bsmith) from comment #111)
> De-noming because it looks like it will be a while and it looks like I was
> mistaken in considering it a blocker when I nominated it. I should have
> marked it tracking-b2g instead, but AFAICT I cannot do that in the NSS
> product.

Okay, tef- but please nominate any patches for uplift to the relevant b2g branch when they are ready. It looks like the tracker flag isn't on all products so I think the approval on the patch(es) is the best we can do. Oh, I'll also accept private email to get attention to this :)

Today I have seen than CPS was update on July. Rafa, there are any other update?

It's important update information to try to resolve this bug.

The Root certificate download URL is not longer valid.
You can found it here:
https://www.sede.fnmt.gob.es/descargas/certificados-raiz-de-la-fnmt

Created attachment 8360595
UPDATED CAInformation.pdf

It wasn't clear to me which information I had was current or outdated. So I created a new CAInformation document (attached).

Within this document, 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.

131 comments hidden view all 160 comments
1 comments hidden view all 160 comments

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.

tags: added: patch
tags: added: trusty
Changed in thunderbird (Ubuntu):
importance: Undecided → Low
summary: - "AC Raíz FNMT-RCM.crt" is missing from Firefox
+ "AC Raíz FNMT-RCM.crt" is missing from Firefox and Thunderbird

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

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

1 comments hidden view all 160 comments

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.

2 comments hidden view all 160 comments
summary: - "AC Raíz FNMT-RCM.crt" is missing from Firefox and Thunderbird
+ "AC Raíz FNMT-RCM.crt" is missing from Mozilla products
2 comments hidden view all 160 comments
summary: - "AC Raíz FNMT-RCM.crt" is missing from Mozilla products
+ fnmt.es certificates are not included in Mozilla products
summary: - fnmt.es certificates are not included in Mozilla products
+ www.cert.fnmt.es certificates are not included in Mozilla products
description: updated
Changed in firefox:
importance: Unknown → Low
status: Unknown → New
Changed in thunderbird:
importance: Unknown → Low
status: Unknown → New
tags: added: bytezise
6 comments hidden view all 160 comments
1 comments hidden view all 160 comments

Created attachment 8363633
Certificates.tar.gz

Created attachment 8363634
Certificates.tar.gz

Created attachment 8363635
Certificates.tar.gz

2 comments hidden view all 160 comments

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.]

tags: removed: patch
3 comments hidden view all 160 comments

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.

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.
>

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

Thank you.

Changed in firefox (Ubuntu):
status: New → Won't Fix
Changed in thunderbird (Ubuntu):
status: New → Won't Fix
Changed in thunderbird:
status: New → Won't Fix
117 comments hidden view all 160 comments

Aboute Potential Constraints on this CA Hierarchy. Would it be reasonable to constrain certificate issuance within this CA hierarchy to certain domains, such as *.es?

Not. There is some domains as *.org with FNMT certificates. Example: https://tramites2.ayuntamientojun.org/to/montarTramiteAction.egim?idTrami=55

Status of this bug: Waiting for response from an official representative of the CA regarding items highlighted in yellow in the document attached to Comment #115.

118 comments hidden view all 160 comments

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 ***

119 comments hidden view all 160 comments

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

Changed in firefox:
status: New → Invalid

Kathleen, maybe it would be a good idea to add the comment number to the whiteboard too, since almost 6 years of comments are difficult to follow ;)

Comment to FNMT:
Resolution of this bug is also blocked the inclusion of CA in Android's trust store.

You can see http://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=53195 for more information.

Adolfo Jayme (fitojb) on 2014-06-18
Changed in firefox:
importance: Low → Unknown
status: Invalid → Unknown
Changed in firefox:
importance: Unknown → Wishlist
status: Unknown → In Progress

I keep telling my family in the cuisine you can distinguish bad management because two things:

1. Lots of unfinished work in sight.
2. Lots of speaking being exchanged.

The reason is always the same: there isn't really anybody taking care of the process, but just some people blindly working in smoke.

So stop working and start solving. Perhaps it will take you moths, but not years.

Created attachment 8534334
General CPS applicable to all FNMT's CAs (aproved on 10/2014)

Updated General CPS includes:
- Periodicity of one year to the fulfilment of audits
- Prohibition to issue CA certificates to other different entities to FNMT-RCM.
- Limitation to a maximum of 3 years the period of validity of the end-entity certificates.

Also, I attach reference to WebTrust seal recently obtained:

https://cert.webtrust.org/ViewSeal?id=1784

Created attachment 8535573
Truthful translation of "AC Componentes" CPS

Truthful and complete translation into English of new software component CA.

Created attachment 8535578
"CA Administracion Pública" CPS for Public Organizations and Administrations

Updated version of specific CPS of CA for Public Organizations and Administrations

Created attachment 8536614
CA Information: pending questions

Which of the 3 trust bits (Websites, Email, Code Signing) are you requesting to have enabled for the
AC RAIZ FNMT-RCM root? My notes says "Websites, Code Signing".

The Seal file that you attached in Comment #124 is for "WebTrust for Certification Authorities -- SSL Baseline Requirements version 2.0", which is only regarding SSL cert issuance.
Does FNMT have other current audit statements, such as WebTrust for CA, ETSI TS 102 042 or ETSI TS 101 456?
See section 11 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
If yes, please provide the link to them.

Created attachment 8549906
435736-CAInformation.pdf

I have entered the information for this root inclusion request into SalesForce. Please double-check the attached document for accuracy, and search for "Need Response" to see the remaining questions.

Hi Kathleen.

We are requesting to have enabled for Websites and Code Signing.

We thought that "WebTrust for Certification Authorities" audits was enough for that.

Anyway, we have already started an ETSI 101 456 audit process and we expect to have concluded it in a few months

Changed in firefox (Ubuntu):
status: Won't Fix → In Progress
Changed in thunderbird (Ubuntu):
status: Won't Fix → In Progress
Changed in thunderbird:
importance: Low → Unknown
status: Won't Fix → Unknown
Changed in firefox (Ubuntu):
importance: Low → Wishlist
Changed in thunderbird (Ubuntu):
importance: Low → Wishlist
Changed in thunderbird:
importance: Unknown → Wishlist
status: Unknown → In Progress

Hi Kathleen,

We are contacting you as we are facing the following question:

As internal consultancy service of FNMT we are surprised that besides the accreditation “SSL Baseline Requirements Audit Criteria”, FNMT was asked for "Principles and Criteria for Certification Authorities 2.0”.

As far as we know the principles of both standards are identical, except for technical network security specifications “SSL Requirements Baseline Audit Criteria” as shown in the following matrix::

WT CA 2.0 WT BR SSL 2.0
CA Principles Principles
P1. CA Business Practices Disclosure P1. Baseline Requirements Business Practices Disclosure
P2. CA Environmental Controls P3. CA Environmental Security
P3. Service Integrity P2. Service Integrity
                                             P4. Network and Certificate Systems Security Requirements

We consider that is enough to comply with “SSL Baseline Requirements Audit Criteria” for the certifications under the scope. Would you be so kind to let us know the reason to ask for both standards? Based on our understanding, this situation increases the costs of accreditation for quality, security and reliability of WebTrust, ... in addition to cause confusion.

Please, we would like to clarify this issue.

Best regards

(In reply to Antonio from comment #131)

I posted your question in the mozilla.dev.security.policy discussion forum:
https://groups.google.com/d/msg/mozilla.dev.security.policy/gAyPrxZezqo/Q1RAiLfZUD8J

(In reply to Kathleen Wilson from comment #132)
> (In reply to Antonio from comment #131)
>
> I posted your question in the mozilla.dev.security.policy discussion forum:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/gAyPrxZezqo/
> Q1RAiLfZUD8J

Here's the answer:
They are completely different in their application. SSL Baseline only cover the CAB baseline requirements and do not cover the more detailed requirements for WebTrust certification (and initial acceptance). WebTrust for CA covers accepted practices for a CA - additional SSL Baseline were brought in just to deal with specific additional issues.

(In reply to Kathleen Wilson from comment #129)
> Created attachment 8549906
> 435736-CAInformation.pdf
>
> I have entered the information for this root inclusion request into
> SalesForce. Please double-check the attached document for accuracy, and
> search for "Need Response" to see the remaining questions.

Dear Kathleen,

Indeed, new version of CPS and PC that are within the scope of the certification will comply with the requirement of the “WebTrust SM/TM for Certification Authorities WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security”. However, for the sake of coherence, it was not possible to consider such statement but after finishing the audit.

It will be included the following text:

FNMT-RCM conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

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

Best regards

(In reply to Antonio from comment #134)
> Indeed, new version of CPS and PC that are within the scope of the
> certification will comply with the requirement of the “WebTrust SM/TM for
> Certification Authorities WebTrust Principles and Criteria for Certification
> Authorities - SSL Baseline with Network Security”. However, for the sake of
> coherence, it was not possible to consider such statement but after
> finishing the audit.
>
> It will be included the following text:
>
> FNMT-RCM conforms to the current version of the Baseline Requirements for
> the Issuance and Management of Publicly-Trusted Certificates published at
> https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any
> inconsistency between this document and those Requirements, those
> Requirements take precedence over this document.
>
> We remain at your disposal for any further clarification concerning this
> topic.

Please clarify if you intend to add that statement to the CP/CPS, or if you are saying it will be part of the audit statement only.

For reference, I asked in the discussion forum about having the BR commitment to comply in the audit statement only:
https://groups.google.com/d/msg/mozilla.dev.security.policy/wsw2G-PFKiA/akU0bhzN8MMJ
It looks to me like the answer will be that it needs to be in the CP/CPS. You are welcome to participate in that discussion.

(In reply to Kathleen Wilson from comment #135)
> (In reply to Antonio from comment #134)
> > Indeed, new version of CPS and PC that are within the scope of the
> > certification will comply with the requirement of the “WebTrust SM/TM for
> > Certification Authorities WebTrust Principles and Criteria for Certification
> > Authorities - SSL Baseline with Network Security”. However, for the sake of
> > coherence, it was not possible to consider such statement but after
> > finishing the audit.
> >
> > It will be included the following text:
> >
> > FNMT-RCM conforms to the current version of the Baseline Requirements for
> > the Issuance and Management of Publicly-Trusted Certificates published at
> > https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any
> > inconsistency between this document and those Requirements, those
> > Requirements take precedence over this document.
> >
> > We remain at your disposal for any further clarification concerning this
> > topic.
>
>
> Please clarify if you intend to add that statement to the CP/CPS, or if you
> are saying it will be part of the audit statement only.
>
> For reference, I asked in the discussion forum about having the BR
> commitment to comply in the audit statement only:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wsw2G-PFKiA/
> akU0bhzN8MMJ
> It looks to me like the answer will be that it needs to be in the CP/CPS.
> You are welcome to participate in that discussion.

Dear Kathleen,

The following statement will be added in the next version of the CP/CPS:

"The FNMT-RCM manages its certification services and issues certificates in accordance with the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” established by the CA/Browser Forum and which can be consulted in the following link: https://cabforum.org/baseline-requirements-documents/

The FNMT-RCM shall review its certification policies and practises in order to keep them in line with the referred requirements. In light of the publication of new versions of that document of requirements, The FNMT-RCM shall act diligently to address any deviation or, where appropriate, notify in this document any incurred noncompliance."

Best regards.

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

(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.

(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

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

(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?

(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/

Changed in firefox:
status: In Progress → Fix Released
Changed in thunderbird:
status: In Progress → Fix Released
Changed in thunderbird (Ubuntu):
status: In Progress → Fix Released
Changed in firefox (Ubuntu):
status: In Progress → Fix Released
Displaying first 40 and last 40 comments. View all 160 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.