2062162 - HARICA: TLS server certificate issuance against CP/CPS

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[JohnD]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

HARICA's own CPS latest here: https://repo.harica.gr/documents/CPS-EN-4.13.pdf

Section 3.1.5:
"The Distinguished Name in each Subscriber Certificate must be unique for each Issuing
CA, while it is desirable to be unique in the entire HARICA hierarchy."

Under various HARICA CAs, there are tens or hundreds of thousands of certificates with duplicate DNs that must now be revoked.

I raised the issue to HARICAs CPR address on 1 aug 2026, they did not reply (aside from standard autoreply) for almost 3 days on 4 aug 2026.
That may need a separate incident report, so I expect two bugs opened.

The reply stated that they did not consider it a misissaunce or reason to revoke.

I did not agree with the reasons, for my own simple reason that their CPS clearly states what they claim to do.

I see lots of discssuions and bugs about CPS/CP problems lately.

Some are not so clear where language uses word and phrases that can be interpreted differently.

Some like this for HARICA and Acttalis and iTrustChina are more clear as the words are clear and definite.
For HARICA - 'desirable' for not having same DN across whole of HARICA.
'must be unique for each Issuing CA' is clear, definite.

The DN does not include serial number.

Comment 1

[HARICA]

(In reply to JohnD from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

HARICA's own CPS latest here: https://repo.harica.gr/documents/CPS-EN-4.13.pdf

Section 3.1.5:
"The Distinguished Name in each Subscriber Certificate must be unique for each Issuing
CA, while it is desirable to be unique in the entire HARICA hierarchy."

Under various HARICA CAs, there are tens or hundreds of thousands of certificates with duplicate DNs that must now be revoked.

I raised the issue to HARICAs CPR address on 1 aug 2026, they did not reply (aside from standard autoreply) for almost 3 days on 4 aug 2026.
That may need a separate incident report, so I expect two bugs opened.

Regarding the CPR process, we would like to set out the sequence of events, since the timeline described in the report is not complete (all timestamps are in EEST):

• 2026-08-01 19:08:03: The Certificate Problem Report was received by HARICA.
• 2026-08-01 22:51:48: HARICA responded to the reporter, three hours and forty-three minutes after receipt.
• 2026-08-04 09:52:14: HARICA sent its final determination, following completion of the investigation.

That response was not an automated reply. It was sent by our Support Team following a triage of the report, carried out to establish that the CPR involved Certificates issued by HARICA and to identify the population at issue. It read:

Thank you for bringing this matter to our attention.

We acknowledge receipt of your report. HARICA is reviewing the information provided and will investigate the matter in accordance with its CP/CPS and the applicable requirements.

We will provide you with a further update once our initial assessment has been completed.

The report concerned a large population of Certificates across 13 Issuing CAs and raised a question of interpretation of our CP/CPS. Section 4.9.5 requires the investigation to begin within 24 hours and a preliminary report to be provided in that period, and the determination on revocation to be completed within the time frame of section 4.9.1.1. Both were met.

In any event, a templated first response has been considered acceptable in this forum before: for example, in bug 1671113, the Mozilla Root Store representative raised an automated response template as an appropriate measure (comment 8), and the bug was closed on the basis that the CA would implement it (comment 10).

We see no violation of section 4.9.5 in the handling of this Certificate Problem Report, and therefore, we do not consider a separate incident report to be required.

The reply stated that they did not consider it a misissaunce or reason to revoke.

I did not agree with the reasons, for my own simple reason that their CPS clearly states what they claim to do.

I see lots of discssuions and bugs about CPS/CP problems lately.

Some are not so clear where language uses word and phrases that can be interpreted differently.

Some like this for HARICA and Acttalis and iTrustChina are more clear as the words are clear and definite.
For HARICA - 'desirable' for not having same DN across whole of HARICA.
'must be unique for each Issuing CA' is clear, definite.

The DN does not include serial number.

For full transparency, we set out below the Certificate Problem Report as received and our final response to it:

CPR message begins

johndoejohn@XXXXX High Priority Certificate Problem Reporting
Jon Doe
Tel: +XXXXXXX
Section 3.1.5 (Uniqueness of names) of HARICAs current CPS states:
"The Distinguished Name in each Subscriber Certificate must be unique for each Issuing
CA, while it is desirable to be unique in the entire HARICA hierarchy."
13 HARICA CAs contain certificates with multiple non-unique DNs.
A total of over 730,000 DNs are represented, which will cover at least double that amount
of certificates that are in violation of your CPS and as such need to be revoked.
I expect a reply within 24 hours of 18:10 CET on 2-Aug-2026, and a plan to open an
incident in Bugzilla, list all certificates with non-unique DNs in violation of your own
CPS and revocation of the certificates within the required window.

CPR message ends

CPR response begins

Dear Reporter,

Further to our acknowledgement of your report, we have now completed our assessment.
HARICA has investigated the reported issuance of multiple Subscriber Certificates containing the same Subject Distinguished Name (Subject DN), including the relevant certificate records, the validated Subject information and the Subscriber information. We do not consider this to be a violation of sections 3.1.2 or 3.1.5 of our CP/CPS, for the reasons set out below.

Section 3.1.2 of the CP/CPS provides:

> The names that are included in Certificates must be related to the Subscriber. They must also be meaningful, unambiguous and produce unique DNs per Issuing CA per Subscriber. In cases where the common name (CN) or any other element would produce an ambiguous or non-unique DN per Subscriber, or where for any reason a CN is not present, HARICA will utilize a unique ID and/or serial integer in the Subject DN to identify a Certificate in a unique way.

The purpose of these provisions is to prevent collisions, that is, to ensure that a Subject DN issued by a given Issuing CA identifies one entity and not two. The requirement is accordingly scoped per Subscriber: an Issuing CA must not assign the same Subject DN to two different Subscribers. It does not require a distinct Subject DN for every Certificate, including Certificates issued to the same Subscriber. The obligation in the second sentence to add a unique ID or serial integer is conditional, arising only where the DN "would produce an ambiguous or non-unique DN per Subscriber", which is not the case here.

This follows RFC 5280 section 4.1.2.6: "The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field. A CA MAY issue more than one certificate with the same DN to the same subject entity." Individual Certificates remain uniquely identifiable by Issuer name and serial number, per RFC 5280 section 4.1.2.2.

Section 3.1.5, which your report cites, states the same requirement in short form: "The Distinguished Name in each Subscriber Certificate must be unique for each Issuing CA, while it is desirable to be unique in the entire HARICA hierarchy." It carries the same scope as section 3.1.2, which is the provision that defines what uniqueness of names means in our CP/CPS and is titled accordingly ("Obligation for meaningful names"). Section 3.1.5 does not impose a separate or wider requirement.

Were the Subject DN of every Certificate required to be distinct, sections 3.1.2 and 3.1.5 would also conflict with section 4.6.3 of our CP/CPS, under which a renewed Certificate is issued using the original CSR and therefore carries the same Subject DN as the Certificate it renews.

Our investigation confirmed that the repeated Subject DNs in the reported population corresponded to the same respective Subjects. For identity-aware Certificates, the repeated organization information referred to the same respective validated Subjects, which are also the Subscribers. For DV Certificates, the repeated Subject DNs concerned the same validated domain names; the identity of the Subscriber is not a validated attribute in DV Certificates, and the Subject DN accordingly reflects the validated domain name rather than the identity of the Applicant. We found no instance of a collision, that is, of the same Subject DN identifying different entities.

We therefore consider this Certificate Problem Report closed without certificate revocation. If you have identified specific Certificates which constitute such a collision, please send them to us and we will investigate further.

CPR response ends

The reasoning is set out in full above. We would add only that the provisions of a CP/CPS are to be read in context and as a whole, rather than clause by clause in a vacuum. Section 3.1.5 states in short form the requirement that section 3.1.2 defines, and a reading of either provision that required a distinct Subject DN for every Certificate could not be reconciled with section 4.6.3, under which a renewed Certificate is issued from the original request/order and therefore carries the same Subject DN as the Certificate it renews.

We accept that section 3.1.5, read on its own, is less precise than section 3.1.2, and we intend to align its wording with section 3.1.2 in a future CP/CPS update. This is a clarification of language that has always been intended to carry the meaning set out in section 3.1.2, and not a change in our practice or a correction of a divergence between the document and our systems.

We do not consider the reported Certificates to be mis-issued, and therefore, we do not consider an incident report to be applicable.