Add ANCERT root CA certificates

RESOLVED INCOMPLETE

Status

NSS
CA Certificate Root Program
P2
enhancement
RESOLVED INCOMPLETE
11 years ago
a year ago

People

(Reporter: Ivan Basart, Assigned: gerv)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 

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

CA Name: ANCERT
Website: www.ancert.com

The Notary Agency of Certification (ANCERT) was constituted in Spain the July of 2002 by the General Council of Notaries (CGN) of Spain with the initial aim to technologically modernize the Spanish notary's collective.
From March the 20th of 2004 ANCERT issues electronic recognized certificates  among persons, companies, public corporations and others according to the requirements of the current regulation (Law 59/2003 from December 19th of the electronic signature).
In the ANCERT infrastructure the Notaries play as RA so that when either person or an entity requires an ANCERT certificate that means a notary must ensure the subscriber identity before the certificate is issued. Additionally ANCERT certificates are recognised by the Spanish Industry Ministry. 
There is more information about ANCERT at www.ancert.com but unfortunately it is only available in Spanish.


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

Certificate Name: ANCERTNOT ( Ancert Notarial )
 - This is the root Certificate of the infrastructure focused to issue certificates to third users which can be
 companies or private individuals. The RA of these Kind of certificates are the Notaries which assure that the 
 certificate holder attributes fit with the certificate information and then issues the certificate. This certificate does not issue final certificates but the following intermediate CA Certificates: ANCERTCP, ANCERTCNC, ANCERTCS (explained bellow).
Certificate HTTP URL (on CA website): http://www.ancert.com/?do=productos&group=certificados_notariales&option=personal&id=certificados
Version: X509 v3
SHA1 Fingerprint: C09A B0C8 AD71 1471 4ED5 E21A 5A27 6ADC D5E7 EFCB
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-11
Valid To (YYYY-MM-DD):   2024-02-11
CRL HTTP URL: www.ancert.com/crl/ANCERTNOT.crl
Class (domain-validated, identity/organisationally-validated or EV):
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps

Certificate Name: ANCERTCNC ( Ancert Notarial Certificates for Corporations  )
 - This CA Certificate issues qualified certificates for corporations according to the Spanish law of electronic signature. The RA of these Kind of certificates are the Notaries which assure that the 
 certificate holder attributes fit with the certificate information and then issues the certificate. The certificate holder must demonstrate that attributes through the documentation required by the CP.
Certificate HTTP URL (on CA website): http://www.ancert.com/?do=productos&group=certificados_notariales&option=corporativo&id=certificados
Version: X509 v3
SHA1 Fingerprint: ADA2 8F80 0D0D 32EA B81E A81C ACAB FE3C 5D09 E45F
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-12
Valid To (YYYY-MM-DD):   2014-02-12
CRL HTTP URL: www.ancert.com/crl/ANCERTCNC.crl
CP URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=corporativo&id=politica
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps

Certificate Name: ANCERTCNP ( Ancert Notarial Personal Certificates )
 - This CA Certificate issues qualified certificates for private individuals according to the Spanish law of electronic signature. The RA of these Kind of certificates are the Notaries which assure that the 
 certificate holder attributes fit with the certificate information and then issues the certificate. The certificate holder must demonstrate that attributes through the documentation required by the Certification Policy.
Certificate HTTP URL (on CA website): http://www.ancert.com/?do=productos&group=certificados_notariales&option=personal&id=certificados
Version: X509 v3
SHA1 Fingerprint: 9882 F23C 9551 E846 7AE3 3CB2 32DE CE31 41EC 1637
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-12
Valid To (YYYY-MM-DD):   2014-02-12
CRL HTTP URL: www.ancert.com/crl/ANCERTCP.crl
CP URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=personal&id=politica
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps

Certificate Name: ANCERTCNS ( Ancert Notarial Certificates for Systems )
 - This CA Certificate issues SSL certificates for systems . The RA of these Kind of certificates are the Notaries which assure that the 
 certificate holder attributes (mainly the FDQN) fit with the certificate information and then issues the certificate. 
Certificate HTTP URL (on CA website): 
http://www.ancert.com/?do=productos&group=certificados_notariales&option=servidor_seguro&id=certificados
Version: X509 v3
SHA1 Fingerprint: AA43 237C 5A92 CC2D 32F9 2D5A 2222 4673 755E FDA3
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-12
Valid To (YYYY-MM-DD):   2014-02-12
CRL HTTP URL: www.ancert.com/crl/ANCERTCS.crl
CP URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=servidor_seguro&id=politica
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps


Certificate Name: ANCERTCGN ( Ancert General Council of Notaries )
 - This is the root Certificate of the infrastructure focused to issue certificates to the Notaries themselves as well as their employees in order to let them identificate as that category. This certificate does not issue final certificates but the following intermediate CA Certificates: ANCERTFERN and ANCERTCE (detailed bellow).
Certificate HTTP URL (on CA website):  http://www.notariado.org/n_tecno/feren/cert_raiz1.htm
SHA1 Fingerprint: 11C5 B5F7 5552 B011 669C 2E97 17DE 6D9B FF5F A810
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-11
Valid To (YYYY-MM-DD):   2024-02-11
CRL HTTP URL: www.ancert.com/crl/ANCERTCGN.crl
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps

Certificate Name: ANCERTFERN ( Ancert Qualified Electronic Signature for Notaries )
 - This CA Certificate issues qualified certificate to Notaries belonging to the CGN of Spain according to the Spanish law 24/2001.
Certificate HTTP URL (on CA website):  http://www.notariado.org/n_tecno/feren/cert_raiz1.htm
SHA1 Fingerprint: BB5A 6CDF 6882 BDA1 9DFC 8260 5911 BA96 3BB0 A651
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-11
Valid To (YYYY-MM-DD):   2024-02-11
CRL HTTP URL: www.ancert.com/crl/ANCERTFERN.crl
CP URL: http://www.notariado.org/n_tecno/feren/CP_FERN.pdf
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps

Certificate Name: ANCERTCE ( Ancert Notary Employees )
- This CA Certificate issues qualified certificate to the Notaries employee belonging to the CGN of Spain according to the Spanish law 24/2001.
Certificate HTTP URL (on CA website):  http://www.notariado.org/n_tecno/ceremp/cert_raiz1.htm
SHA1 Fingerprint: 3EA6 664E FA99 BA8F 706A 6B21 9A7F 4983 AD0E E034
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2004-02-12
Valid To (YYYY-MM-DD):   2014-02-12
CRL HTTP URL: www.ancert.com/crl/ANCERTCE.crl
CP URL: http://www.notariado.org/n_tecno/ceremp/archivos/CP_CE.pdf
CPS URL: http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Mr Basart,

We do not include intermediate certificates in our store. Are all these certificates apart from the first one intermediate certificates?

Also, some certs on your website e.g.
http://www.notariado.org/n_tecno/feren/archivos/ANCERTCGN.crt
are served with Content-Type "text/plain", which makes them hard to import into Firefox. Others, e.g.
http://www.ancert.com/?do=productos.getDocuments&group=certificados_notariales&option=personal&id=163
use "application/octet-stream".

Could you change the Content-Type configuration on the webserver so that it uses "application/x-x509-ca-cert"?

- This page
http://www.ancert.com/?do=productos&group=certificados_notariales&option=declaracion&id=cps
has three CPSes. Which one or ones apply?

Gerv
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

11 years ago
Hello Gervase,

First of all thanks for your quick reply. However now I'm a bit confused, let's see if you can give me some light.

1) How Firefox manage the intermediate certificates? If you don't have an intermediate certificates store how Firefox can verify the complete trust chain? I have tried accessing through SSL to our web page with the root Certificate installed in the Authorities store and I received an alert? I think the reason is that the SSL Cert is not issued by the Root Cert (ANCERTNOT) but by an intermediate one (ANCERTCS). But if there is no way to include the intermediate certificate all the SSL Certs issued by ANCERT (using ANCERTCS) will generate this alert anyway so then where is the benefit of including the Root (ANCERTNOT) in the Authorities store?

2) About the certificates MIME object I will try to talk with our technicians to deal that issue, but why does Firefox need to import the Certificates that way? I mean if I provide you the certs ( I sent you a ZIP file ) I suppose the inclusion process is that they are included in the following Firefox build, isn't it?

3) The current CPS is the most recent one (CPS ANCERT_v13.pdf), we already show the old ones for backward compatibility.

I hope you can solve some of my questions. Many thanks in advance.
1) The standards require that web servers send copies of all certificates in their certificate chain (apart from the root) during the handshake. This is where Firefox obtains the intermediate certificates. As long as all members of the chain are then present (including the root, which is embedded in Firefox) then Firefox will not raise an alert.

As I understand it, Internet Explorer does not stick to the standards in this regard; it has some other mechanisms for obtaining the intermediate certificates which work in some cases. But Firefox and other browsers do not.

2) I apologise for the confusion. This is not the mechanism by which we will include the certificates in our root store for all users. However, if an individual Firefox user (such as me) wishes to import the certificate themselves into their personal store, then the certificates need to be served with the correct MIME type.

Gerv
(Reporter)

Comment 4

11 years ago
Thanks again for you quick response.

1) As you mention IE does not work the same way, that's the reason I was confused. I think it only takes care about the server certificate (not the full chain but just the leaf certificate) and verifies the full chain against the OS certificate store (both intermediate and root certificates).
To be honest I didn't know the SSL standard force to show the full chain during the handshake, in that case I think we have our webserver wrongly configured because only presents the leaf certificate. Do you know by chance how to configure an Apache to show the full chain??

2) I agree that it would be nice to use the appropriate MIME type but you can also install the certs by downloading them in a file and importing then the cert in Firefox. I will try to manage changing the MIME object, but anyway is that a requirement to go on with the certificate inclusion at Firefox?

Thanks again.
Ivan.
Nelson: do you know of a FAQ or other document which explains the situation with intermediate certificates?

Ivan: No, 2) is not a requirement for inclusion :-)

Gerv
The SSL 3.0 specification 
    http://wp.netscape.com/eng/ssl3/draft302.txt

and the TLS RFCs
    http://www.rfc-editor.org/rfc/rfc2246.txt
    http://www.rfc-editor.org/rfc/rfc4346.txt

all require the SSL/TLS server to send the entire chain up to (and 
optionally including) the root CA cert.  There is no RFC that says 
"No, you don't have to do that any more".

Ever since the beginning of SSL 3.0, there have always been servers that
were misconfigured and did not send out their entire cert chain, making 
it impossible for clients to verify the complete chain, UNLESS they have
copies of the missing intermediate certs somewhere.

Microsoft has evidently chosen to reduce the frequency with which their
users experience that problem, by saving a copy of all the intermediate
CA certs that they get when they do validate a complete cert chain.
As far as I know, Windows does not come with any intermediate CA certs
preinstalled.  Rather, a Windows system builds up its collection of 
intermediate CA certs as it visits correctly configured SSL servers. 
When you install a new Windows system, if the very first https server
you visit sends out an incomplete cert chain, you will have the very same
experience with IE that you have with Mozilla browsers, the chain cannot be
validated because it is incomplete.  But after you've visited one server
with all the necessary intermediate CA certs, if you then go back to the
server with the incomplete chain, IE will complete the handshake, because 
the missing certs can be filled in from IE's local store.  

Note that this approach does not work for browsers in PDAs, cell phones, 
and other small devices, because they typically lack the storage needed 
for those intermediate CA certs.

Most server admins have NO IDEA what the standards require, and they 
assume that whatever Microsoft does must be the standard.  They observe
that many users can use their servers, even if their servers are not 
configured to deliver the intermediate CA certs, and so they assume that
there is no requirement that they must do so.  This is the unintended 
consequence  of trying to help users with misconfigured servers.  It 
increases the number of misconfigured servers.  

RFC 3280 (the IETF RFC defining certs) defines the "Authority Information 
Access" (AIA) extension, and a "CA Issuers" Object ID (for use within that
extension), which is accompanied by a "GeneralName" which may be an email 
address or DNS name or URL.  It is defined (rather vaguely) as follows:

   The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates superior to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user.

That's it.  There is No description (and hence no standard) for what the 
relying party (the person using the cert chain) should do with the 
GeneralName for this OID.  Send an email to the RFC822 email address?
Send a GET request to the URL?  Or a POST request?  
And there is no description of what should be returned from such a URL,
whether it should contain one cert, or all the issuer certs for this CA,
and what MIME type should they be?  etc.

The use of the AIA extension is evolving.  I believe eventually most CAs
will put them in the certs they issue, and there will be a defacto standard
(if not a real one) on how browsers use that GeneralName to fetch the 
issuer's certs (there may be more than one).  When that day comes, I believe
the IETF TLS working group (WG) may choose to reconsider whether SSL/TLS 
servers should still be required to send out complete cert chains, and they
may issue a new revised definition of TLS that no longer requires servers 
to send a complete cert chain.  

But until the day that a new TLS RFC is published that no longer requires it,
TLS servers must continue to send complete cert chains.  

In any case, I fully support mozilla's current policy of not accepting new
intermediate CA certs into the browser's read-only store of CA certs.

Finally, I will add that there does appear to be more than one root CA 
among the numerous URLs cited above.  Gerv, I think you should ask the 
CAs to attach copies of their certs to these bugs.  The contents of the
attachments cannot be altered thereafter, but the MIME types can be altered
at will.  :)
(Reporter)

Comment 7

11 years ago
Created attachment 266343 [details]
Ancert Certificados Notariales Root Certificate
(Reporter)

Comment 8

11 years ago
Created attachment 266344 [details]
Ancert Certificados CGN Root Certificate
(Reporter)

Comment 9

11 years ago
Hi Nelson,

Really helpful explanation about how the browser manages the intermediate certificates according to standards. As you proposed I have added the attachments with the root certificates.

Please Gerv, let me know which are the next steps to be performed.

Many thanks,
Ivan.
Ivan: can I confirm that these two roots correspond to numbers 1 and 5 in your list in the first comment?

Gerv
(Reporter)

Comment 11

11 years ago
Exactly
Priority: -- → P2
Ivan: I have some questions :-)

- Which types of use are you requesting for your certificates (email and/or SSL and/or code-signing)?

- Do you offer OCSP revocation service?

- Do all the certificates you issue require an identity check?

- Your webserver is misconfigured in various ways, which make it difficult for individual users to import your certificates and CRLs into Firefox.

This certificate:
http://www.ancert.com/?do=productos.getDocuments&group=certificados_notariales&option=personal&id=163
is served as Content-Type "text/html", and
http://www.notariado.org/n_tecno/feren/archivos/ANCERTCGN.crt
is served as "text/plain". The correct type is "application/x-x509-ca-cert". 

Also,
http://www.ancert.com/crl/ANCERTNOT.crl
and
http://www.ancert.com/crl/ANCERTCGN.crl
are both served as "text/plain". The correct MIME type is "application/pkix-crl".

Please could you contact your web team and ask them to fix this?

Thanks,

Gerv
Summary: ANCERT request to certificate inclusion at Mozilla → Add ANCERT root CA certificates
Please also tell us how you comply with sections 8, 9 and 10 of our CA policy: http://www.mozilla.org/projects/security/certs/policy/ (the sections relating to audits).

Thanks,

Gerv
(Reporter)

Comment 14

11 years ago
(In reply to comment #12)
> - Which types of use are you requesting for your certificates (email and/or SSL
> and/or code-signing)?
>
 
For the Certificates issued at the ANCERTNOT hierarchy, can be used for email, SSL and code-signing.
For the Certficitaces issued at the ANCERTCGN hierachy, can be used for email and SSL. 




> - Do you offer OCSP revocation service?
> 
Not at the moment.




> - Do all the certificates you issue require an identity check?
> 
Yes, and this identity check is performed by a Notary. 



> - Your webserver is misconfigured in various ways, which make it difficult for
> individual users to import your certificates and CRLs into Firefox.
> 
> This certificate:
> http://www.ancert.com/?do=productos.getDocuments&group=certificados_notariales&option=personal&id=163
> is served as Content-Type "text/html", and
> http://www.notariado.org/n_tecno/feren/archivos/ANCERTCGN.crt
> is served as "text/plain". The correct type is "application/x-x509-ca-cert". 
> 
> Also,
> http://www.ancert.com/crl/ANCERTNOT.crl
> and
> http://www.ancert.com/crl/ANCERTCGN.crl
> are both served as "text/plain". The correct MIME type is
> "application/pkix-crl".
> 
> Please could you contact your web team and ask them to fix this?
> 

Yes I'll try to fix that.

(Reporter)

Comment 15

11 years ago
(In reply to comment #13)
ANCERT is considered as a recognized Certification Authority by the Spanish government as you can see at the following link of the Industry Ministry:

http://www11.mityc.es/prestadores/busquedaPrestadores.jsp


About the certifications we are currently being audit in order to align our procedures with ETSI 101 456 and 102 042 and we are planning to pass the WebTrust on September.
Ivan: We require an audit to one of those standards for inclusion. So what I suggest is that we resolve this bug as INCOMPLETE, and you file a new one once the relevant audit has been completed. Unless you anticipate that being very soon?

Gerv
(Reporter)

Comment 17

11 years ago
Hi Gerv,

It won't be sooner than September. Anyway, creating a new bug means filling again all the info presented in this bug? Then may be would be easier using this bug again when we have the audit ready...
Sure - reopen this bug if you prefer. :-) You filed it, so you have permissions to do that.

Gerv
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE

Updated

a year ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.