Closed Bug 1313874 Opened 8 years ago Closed 8 years ago

SHA-1 issuance by Root CA Generalitat Valenciana (Government of Spain) root

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: gerv, Assigned: kwilson)

References

Details

In mozilla.dev.security.policy, Patrick Figel writes:

<blockquote>
I found a number of SHA-1 certificates chaining up to CAs trusted by
Mozilla that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos
to censys for making this search incredibly easy.

...

#6
Don't know what to make of this one. It's a CA:true SHA-1 certificate.
Not sure what the BRs/Mozilla's policies have to say about this:
https://crt.sh/?id=21888899&opt=cablint
  Common Name: ACCV-CA3
  Serial: 1246797330
  Not Before: May 23 10:00:00 2016 GMT
  Chains to: "Root CA Generalitat Valenciana" (Government of Spain)
</blockquote>

These issuances are in violation of the Baseline Requirements, which Mozilla policies require adherence to. Please can you explain what has happened? This is a CA certificate and so must/should have been issued with considerable care. It is therefore very surprising that a SHA-1 certificate has been issued.

Gerv
Note that the "Root CA Generalitat Valenciana" (Government of Spain) is scheduled to be removed per CA request via Bugzilla Bug #1272158.
Well, if they don't respond to this, it might end up getting removed a bit quicker than they wanted... :-|

Gerv
Hi everyone,



At first, our apologies if this situation cause complications. It is not our intention.


I will try to explain:

- 1) It is not a new SubCA, is an old SubCA that we needed resealing, and that for reasons of technical compatibility, resealed with the same attributes as the original.

- 2) The old SubCA (before resealing) had never issued SSL or code signing certificates, only user (personal) certificates for organizations. These certificates were issued under our full control.

- 3) After resealing, that SubCA has only sealed CRLs, it has not issued any new certificate. As I mentioned, it was resealed for compatibility with the aim of sealing CRLS. All our CAs are controlled directly by us. There is no way that any certificate signed by SubCA is issued.

- 4) In fact, that SubCA belongs to a root CA that can be removed from store. I wrote an email on this subject a few days ago. Specifically "Root CA Generalitat Valenciana" (Government of Spain)" can be removed. This action can be done when you decide.


So you can see that is a reseal, attached the two links:

- Before:

http://www.accv.es/fileadmin/Archivos/certificados/accv-ca3_OLD.crt

- After:

http://www.accv.es/fileadmin/Archivos/certificados/accv-ca3.crt

You can see it also in crt.sh

https://crt.sh/?caid=13439   (In the list appear the two associated certificates to the same SubCA).


And check that no registered certificates that have been issued with this SubCA.

https://crt.sh/?Identity=%25&iCAID=13439


If you need any clarification from us, please, tell us.

As always, thank you very much for everything.

Best regards, Jose Antonio
Jose Antonio: it is clear from the links you have given that you resigned the same key with the same parameters because the old intermediate was about to expire. However, the Baseline Requirements clearly state in section 7.1.3:

"Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm."

This may be the same key, but it is clearly a new Subordinate CA certificate. The fact that you may have had systems which depended on it is not a mitigating factor; lots of companies and organizations are needing to go through SHA-1 transitions at the moment. If you needed long-lived SHA-1 intermediates, it was your responsibility to create them before the deadline.

You write:
> As I mentioned, it was resealed for compatibility with the aim of sealing CRLS.

What change did you make between https://crt.sh/?id=12721760 and https://crt.sh/?id=21888899 to improve the compatibility with the task of signing CRLs? The two certificates look identical to me other than the dates and the serial number.

If the plan was only to sign CRLs, why did you not add an EKU extension in order to restrict it to that use?

I realise that you have asked for this root CA to be removed, as recorded in bug 1272158. If this were your only root, this SHA-1 issuance might not be a problem worth worrying about for Mozilla. However, at the time you asked, you gave a removal date in January 2017 and therefore we expect it to be operated in compliance with our root program requirements until that point. Also, the Government of Spain has another root in our trust program, and so the behaviour of the organization is complying with our program requirements is important if we come to assess the status of that root.

> And check that no registered certificates that have been issued with this SubCA.

We are unable to check this using the link provided, because crt.sh is not a repository of all certificates ever issued. It only shows the certificates it knows about.

Gerv
Hi Gerv,

We did not want to create new certificates. Just sign CRLs for compatibility with client systems. This client only used personal certificates.
With this SubCA we have not issued certificates that could be used for SSL or code signing (never). And resealed CA has not issued any certificate.

The signer Root is very old and just let us seal the certificate keeping all parameters (lengthening the lifetime). If we could switch to SHA2 or change the EKU, we would have done.

Of course, we understand that we have made a mistake because we have not assessed the impact. We thought that by not issuing any certificate would have no problem resealing.

It was also a mistake not request the removal of the root prior to resealing.

We would understand that you will want to add that SubCA in OneCRL (although we do not like), in addition to removing the Root requested from the store. We leave it to your discretion.

This removal can do when you want.

Again, our apologies and our guarantee that they have not issued certificates signed by that SubCA, and that mistakes like these have not been produced nor, of course, they occur again.

If you need any further information, let us know.

Best regards, Jose Antonio
(In reply to Gervase Markham [:gerv] from comment #4)
> Also, the Government of Spain has another root in our trust program, and so
> the behaviour of the organization is complying with our program requirements
> is important if we come to assess the status of that root.

Note that "Generalitat Valenciana (Government of Spain)" is a different entity than eg. FNMT, even if both are public entities that ultimately depend on the Government of Spain.
Summary: SHA-1 issuance by Government of Spain root → SHA-1 issuance by Root CA Generalitat Valenciana (Government of Spain) root
Ángel: I was thinking of the root rather unhelpfully known as "ACCVRAIZ1", which is listed here: 
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport 
as belonging to "Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)". That is owned by the same organization, right?

The other CAs listed as being based in Spain are Camerfirma, Firmaprofesional, CATCert, Edicom and Izenpe.

Who are FNMT?

Gerv
(In reply to Gervase Markham [:gerv] from comment #7)
> Who are FNMT?

Ah, found it - bug 435736.

Gerv
Not intended for server use (see also bug 1315018).

Gerv
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.