1947691 - NETLOCK: Bug 1891331 replacement - delayed revocation -

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Nikolett]

We opened a new ticket replacing bug 1891331 summarizing and aswering all the questions of the community. Here you can see the original ticket, the answers can be found in the Appendix.

Summary

Additional IR over https://bugzilla.mozilla.org/show_bug.cgi?id=1889570

NETLOCK was notified on 3 April 2024 that one of our TLS certificate (https://crt.sh/?id=11261465680), signed by our "NETLOCK Trust EV CA 3" (https://crt.sh/?id=11261465680 ) intermediate certificate gives an error on the zlint check (https://crt.sh/?id=11261465680&opt=zlint).
The investigation of the certificate above showed that the TLS certificates issued was created with User Notice field, with
Explicit Text: EV SSL certificate. Terms of service at: http://www.netlock.hu/html/dok.html value which is against BRG 2.0 since Sept. 15, 2023.

Affected intermediate issuers, from where the misissued end-user certificates were signed
• NETLOCK Trust EV CA 3
• NETLOCK Trust Qualified EV CA 3
• NETLOCK DVSSL CA
After the initial investigation NETLOCK started the customer communication and planning the revocation of the affected certificates, as described in the Timeline section of the IR.

Impact

after contacting some of our customers of major importance for the national economy regarding the misissuance of the certificates they requested the extension of the revocation deadline because of their internal procedures they are not able to change some of their certificates in their systems in such a short timeframe

Timeline

All times are CEST

Action timestamp	Action taken
2024-04-03 10:52	E-mail arrived to our central address ([e-mail])
2024-04-05 10:00	direct and undirect customer communication begung on the error
2024-04-05 12:30	Customer responses arriving regarding the new certificates – either accepting the new cert and the expected change date, or objections
2024-04-06 10:00	Revocations started
2024-04-09 13:21	All misissued certificates not requested to be revoked later by the customers (https://bugzilla.mozilla.org/show_bug.cgi?id=1889570) were revoked
2024-04-30 23:59	Certificates requested to be revoked later will be revoked by 2024-04-09 13:21

Root Cause Analysis

The issue originated from the change of the BRG last year. NETLOCK’s staff investigated the changes in the profiles, but unfortunately the change regarding the policy identifier was not updated.
Lessons Learned (Updated)
This issue pointed out that our internal systems monitoring should be improved to catch such issues more affectively. NETLOCK has worked hard in the past period on monitoring external and internal data regarding certificate issuance.

1 What went well

The changes in our internal processes let us handle this issue on a timely manner and we were able to meet the deadlines required by the BRG and Mozilla.

2 What didn't go well

Some of our customers used the related certificates in such systems, where the changing of the certificates cannot be implemented in such a short period of time.

3 Where we got lucky

The security of the certificates was not affected by the misissuance. Therefore NETLOCK decided to extend the revocation period for customers of major importance for the national economy.

Action Items

Action Item	Kind	Due Date
Fix of certification profiles	Repair	2024-04-09
Revoke affected certificates	Repair	2024-04-09
Revoke remaining affected certificates (based on customer requests)	Repair	2024-04-30
Extend monitoring capabilities (linting functionality and post checks)	Remediate	2024-05-31

Appendix

in the bug 1891331, many questions have been raised by the community and we would like to answer them below:

1 Comment 16
Can you clarify where in Netlock's Certificate Policy there is a requirement to revoke within five days?
A previous comment stated: „We strive to steer clear of errors to avoid the need for withdrawals within 5 days.”
We apologise, we made a typo here. The certificates have been revoked within 1 day. As you can see later in the comment, we have given ourselves the 5 day deadline to deliver the new certificates to the users, The 5 days in the first sentence did not refer to the withdrawal it was a mistake on our part. We understood the 24h mark for the revocation time then.

Who is actually responsible for handling revocation?

The Subscriber shall be responsible for: initiating the modification of the certificate, the replacement or revocation of his key in accordance with Sections 9.6.3 and 4.9.1 of the Service Policy and Sections 4.7 and 4.8 hereof;

This inserted part of our policy refers to the case when a user requests the revocation of their certificate.
This question also pointed out that in our Policies and Statements the responsibility of certificate revocation is not clear enough. Our regulatory documents only cover how we will deal with a customer's withdrawal request. In the case of certificate revocation due to a certificate configuration error/misissuance, the provisions are not clear despite the reference of section 4.9.1 of the TLS Baseline Requirements.
As a solution to this problem, it will be included in our Terms and Conditions that if TLS certificates are issued with incorrect content, the Trust Service Provider will be responsible for revoking them in accordance with the BRG Policy, this will be done within 24 hours without exception.
We would like to point out that since this comment was added, our regulatory documents in the CCADB have been corrected. We will continue to pay particular attention to the maintenance of the above documents in the future.

2 Comment 18
Netlock's Certificate Policy does not have 5-day revocation available. Section 4.9.1 only covers 24 hours, and 7 days. Due to this your requirement for revocation was 24 hours.
Yes, the policy does not include the 5 days because that was a typo on our part, apologies. We will take care of this in the future.

Netlock's General Terms and Conditions mention on page 24 that the Subscriber is responsible for revocation. Is this correct?
It is correct in the case of data change. The Subscribers must promptly notify us of any changes to their data that is in a certificate and request the suspension or revocation of their certificates. In case of misissuance the revocation is not the Subscibers responsibility.

Netlock's CCADB entry's for their certificate policy are out of date by years.
We updated the documents and will maintain them in the future as required.

CCADB and Chrome Root Program's have separate policies mandating an authoritative English language version. This needs to be addressed.
It has been adressed. We revised our Policies Ands Statements and get them translated again with help of professional translators. This is still an ongoing process.

I will note Section 2.1.2 as Netlock have created a big problem:

The Service Provider shall, at least 30 days before their entry into force, publish the new versions to be implemented of the Certificate Policy, the Practice Statement and the General Terms and Conditions pertaining to the services based on the present Certificate Policy and affected by the subject modification.
Certificate Policies are effectively contracts attached to certificates by reference, by including this language they are technically non-compliant until 30 days after the Certificate Policy has been published.

We agree with the above. We would like to apologise and clarify the situation:
Yes, our service policies and statemens have a 30-day waiting period. Service Providers here are required to publish the new policy on their website 30 days before this new policy comes into force. This 30 days is the period in which the current regulation document is in force. We see the problem with the above, and as a result of discussions with the supervisory authority, we have come to the conclusion that the 30-day period will continue to apply, but if we detect a discrepancy in the certificate profile or a problem that cannot wait for the 30-day lead time, we have the possibility to immediately amend the new regulatory document and make it available to the supervisory authority for registration and publication on our website and on the CCADB interface. Subject to these, it is possible to deviate from the general procedure, but prior consultation with the authorities is requested and needed. Following the consultation, the CP/S can be immediately modified.

3 Comment21
Hi, can you please provide some references of EU laws associated with Trust Services that support this statement?
Regulation (EU) No 910/2014 (eIDAS) on electronic identification and trust services for electronic transactions in the internal market, provides a regulatory environment for electronic identification of natural and legal persons and for trust services states in Article 24. 2. (a)
2. A qualified trust service provider providing qualified trust services shall:
(a) inform the supervisory body of any change in the provision of its qualified trust services and an intention to cease those activities;

This EU regulation is harmonised into the Hungarian legislation by the DÁP Act, which includes:
XV. FEJEZET A BIZALMI SZOLGÁLTATÁSOK NYÚJTÁSÁNAK ÁLTALÁNOS FELTÉTELEI 43. A bizalmi szolgáltatás nyújtásának megkezdése
83. § (6) A minősített bizalmi szolgáltatást nyújtó bizalmi szolgáltató a változás bevezetését legalább 30 nappal megelőzően értesíti a bizalmi felügyeletet a bizalmi szolgáltatás nyújtásában bekövetkező, tervezett változásokról.

Translation:
CHAPTER XV. GENERAL CONDITIONS FOR THE PROVISION OF TRUST SERVICES
43. Section 83§ (6) A trust service provider providing a qualified trust service shall notify the Supervisory Authority of the planned changes in the provision of the trust service at least 30 days before the change is implemented.
Sidenote: You may see Eüt in our previous ticket: The Eüt was repealed by the DÁP legislation over 2024 autumn.
Changes to our Service Policies and Statements fall within this scope. This "30-day rule" is only applicable for TSPs operated in Hungary because of the more specific rules described in "DÁP."

---

The changes we have made and the solutions we have came up with are the following:

• We have amended our Terms and Conditions, emphasising the 24-hour withdrawal period for TLS certificates. In case of misissuance the certificates will be revoked within 24 hours, no exception.
• Our policies have been revised with the help of a professional translator and the part that English translations do not prevail has been removed.
• NETLOCk has completed the full implementation of Zlinter prior to Certificate Release and we are also listed on GITHUB. - https://github.com/zmap/zlint
• Our regulatory documents have been updated in the CCADB and we are working on keeping them up-to-date.

Our deadlines for the above are as follows, we would like to include an updated Action Items table as the changes are currently in progress.

Action Item	Kind	Due Date
Zlint implementation	Prevent	Completed on 2024.10.04
Monitoring implementation on Certification issuance	Prevent	Completed on 2024-05-31
Monitoring phase 2 implementation on Checking after issuance	Prevent	Completed on 2024-07-31
Terms and condition update with the 24H revocation deadline	Remediate	2025.03.10
Publication of the newly translated Policies	Remediate	2025.03.10.
CCADB documentation update	Remediate	2025.03.10