1512270 - Microsec: Validity period greater than 825 days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

dr. Sándor Szőke posted the following incident report to the mozilla.dev.security.policy list:

1./
How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

2018-11-29 20:15 CET
Microsec received a notification email to the central email address from Alex Gaynor at Mozilla.

In the email Alex Gaynor reported  two misissued certificates:
- https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE&opt=cablint
- https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0

He requested to
a)      revoke these certificates
b)      notify the mozilla.dev.security.policy mailing list with retrospective details as described here: https://wiki.mozilla.org/CA/Responding_To_An_Incident



2./
A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.


2018-11-22 around 16:15 CET
Microsec issued 3 pcs CISCO VPN server certificates.
See details in point 4.

2018-11-29 20:15 CET
Microsec received a notification email to the central email address from Alex Gaynor as described in section 1.

2018-11-29 20:44 CET
Gergely Vanczák (director of the certification services)  forwarded the email to dr. Sándor Szőke (deputy director of the certification services).

2018-11-30 09:27 CET
Gergely Vanczák sent an email to the customer service and ordered to
a)      issue new certificates instead of the reported certificates with two years validity
b)      contact the customer regarding the replacement and agree with them the revocation date of the misissued certificates

2018-11-30 10:50 CET
The customer service reported that there were three similar certificates not only two.

2018-11-30 10:55 CET
Gergely Vanczák ordered to replace all three certificates.

2018-11-30 11:10 CET
The new certificates has been issued with two years validity. The customer has been informed about the replacement due to misissuance. It was on Friday, so the customer asked a few days to be able to arrange the installation of the new certificates in his IT systems.

2018-11-30 20:32 CET
dr. Sándor Szőke informed Alex Gaynor in email about the issuance of the new certificates and the planned revocation of the original certificates.

There was a small discussion between them about the reason of the problem in a few emails in the following half hour. The summary of the details can be seen later.

2018-12-03 10:28 CET
Monday morning the customer informed Microsec that he has successfully replaced all three certificates in his system.
The misissued certificates has been revoked.


3./
Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Our CA issued only those 3 certificates with this problem and it will not happen in the future again.


4./
A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

2018-11-22 around 16:15 CET
Microsec issued 3 pcs CISCO VPN server certificates to the same customer (Hungarian Chamber of State Notaries).

The certificates were issued with three years validity under the ’ Advanced Class 3 e-Szigno CA 2009’ by using the non eIDAS conformant Certification Policies which covers all the certificate types rather than electronic signature and website authentication.

The Common names are:

avpn.mokk.hu
bvpn.mokk.hu
fvpn.mokk.hu



5./
The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

The link to two of those certificates.
https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE&opt=cablint
- https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0

All the three certificates had the same problem, the validity was three years instead of two years.

6./
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Microsec manages the CISCO VPN cerver certificates separately from the TLS certificates. The policy of the CISCO VPN servers was not changed when the validity of the TLS certificates changed from 3 years to 2 years in March 2018.
Microsec issues only a very few CISCO VPN server certificates and these were the first issued certificates since the reduction of the allowed validity time from 3 years to two years.

7./
List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Further actions made:

       Microsec modified the CISCO VPN server policy to issue the certificates only for two years in the future.
       Microsec decided to discuss the situation of the CISCO VPN server certificates and make the necessary modifications (if needed) to fully comply with the BR requirements in case of CISCO VPN server certificates too.

The reason of the problem is that Microsec couldn’t find clear instruction or specifications about the requirements regarding the CISCO VPN server certificates.

They are very similar to the TLS certificates, but they have slightly different usage and different extended key usage values.

The main difference is that the CISCO VPN server certificates contain the following EKU values which should not be present in the TLS certificates:

       ipsecEndSystem (1.3.6.1.5.5.7.3.5),
       ipsecIntermediateSystem (1.3.6.1.5.5.8.2.2)

The easiest way would be to manage the CISCO VPN server certificates as a TLS certificate.
Our questions are:
       is it allowed to issue CISCO VPN server certificates with the same CA which issues TLS certificates?
       will not cause the extra EKU values any problems for the CABF in the (near) future?
       is it possible to send the CISCO VPN server pre-certificates to the CT log servers and include the answers in the certificate?
       is it still really necessary to include these extra EKU values in the CISCO VPN server certificates, or can CISCO devices work with fully TLS compatible certificates?

Comment 1

[Wayne Thayer]

Link to discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/Pcc1_luzwNs/nAtn94GdBQAJ

Comment 2

[Wayne Thayer]

The discussion has completed and no further action is required.