1449371 - E-Tugra: Validity period > 825 days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The following certificate contains a number of errors, including a validity period greater than that allowed by the BRs: https://crt.sh/?id=362986760&opt=cablint,zlint

For the problem listed above, please provide an incident report as described here:

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Davut Tokgöz]

We immeadiately take action to fix this problem and the certificate  is being revoked as soon as possible. The incident report will be provided after root analysis of the problem.

Comment 2

[Davut Tokgöz]

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.
E-Tugra: We first aware from the problem via BugZilla

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.
E-Tugra: The following actions took in response after report.
•	Certificate is revoked immediately and a ner certificate was issued for the certificate owner.
•	All certificate database is searched for the problem is exist more or not. No more certificate is found.
•	The root analysis is applied and we found that why this problem occurs. (the reason of problem is applied in 6)
•	The preissue and postissue control libraries in our system is upgraded and test against the problem. We try to create similar problem is we cannot after upgrade.

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.
E-Tugra: The related certificate was revoked after getting bug notification from Bugzilla and all problems are fixed in our systems.

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.
E-Tugra: There is only one certificate was issued after March 1st, 2018. There is no more certificate with the same problem. 

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.
There is only one certificate with this this problem (over 825 days on validity period) as reported. https://crt.sh/?id=362986760&opt=cablint,zlint

6.	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
E-Tugra: 825 days limitation on validity period of SSL Certificates are implemented and run on February 21st, 2018 and al certificates that issued after March 1st into the system are limited to max 825 days validity period. 
The application of certificate request was done before February 16th and all verification about application was completed on approved for issuing. So, All preinstallation control for data that will be used while issuing will be approved with preissue control routines. But, due payment latency, system will pause the certificate issuing. But the certificate
The payment is completed on March, 14th and the certificate was issued with approved data on Feb, 16th. The approved data covers a validity date over 825 days.
The solution is that the preissue control done by system must be done just before issuing certificate.
To avoid the problem all other waiting certificates application are controlled and the existing preissue validation controls are applied just before issuing the certificate.

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.
E-Tugra: All required measures are taken for now. The certificates are controlled by the system. These are enough for preventing the certificates with these measures.
In addition to the these, a post-issue controls done by system will be extended will be extended with these restriction in 3-6 months.

Comment 3

[Wayne Thayer]

Thank you for the incident report explaining the validity period error.

Please also report on the other BR violations found in this certificate:
   ERROR: BR certificates with organizationName must include either localityName or stateOrProvinceName 
   ERROR: Unallowed key usage for RSA public key (Key Agreement)

Comment 4

[Davut Tokgöz]

Hi,
We will update the Indicent report ASAP

Comment 5

[Davut Tokgöz]

Updated report:
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.
E-Tugra: We first aware from the problem via BugZilla
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.
E-Tugra: The following actions took in response after report.
•	Certificate is revoked immediately and a new certificate was issued for the certificate owner.
•	All certificate database is searched for the problems is exist more or not. 
•	For 825 day limit : No more certificate is found.
•	For missing localityName or stateOrProvinceName : One more certificate is found with similar
•	For key-agreement flag : All server certificates are set with key-agreement.
•	The root analysis is applied and we found that why this problem occurs. (the reason of problem is applied in 6)
•	The pre-issue and post-issue control libraries in our system is upgraded and test against the problems. We try to create similar problem is we cannot after upgrade.

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.
E-Tugra: The related certificate was revoked after getting bug notification from Bugzilla and all problems are fixed in our systems. Also another certificate found with missing Locality or stateOrProvience certificate and issued a new one for the client. All Problem reasons are fixed and no more certificates will be produced with the problems.
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.
E-Tugra: There is only one certificate was issued after March 1st, 2018 for 825 days limit. There is no more certificate with the same problem. 
For the second problem, there one more additional certificate with the same problem and it is being replaced. 
For keyusage problem, all certificates from beginning is issued with the keyaggrement flag. 
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.
There is only one certificate with first problem (over 825 days on validity period) as reported. https://crt.sh/?id=362986760&opt=cablint,zlint 
For the second problem, there one more additional certificate with the same problem and it is being replaced. Its fingerprint is  
For keyusage problem, all certificates from beginning is issued with the keyagreement flag. After getting this error from Bugzilla, it was fixed.
6.	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
E-Tugra: 
For 825 days Limit:
825 days limitation on validity period of SSL Certificates are implemented and run on February 21st, 2018 and al certificates that issued after March 1st into the system are limited to max 825 days validity period. 
The application of certificate request was done before February 16th and all verification about application was completed on approved for issuing. So, All validation control for data that will be used while issuing was done with pre-issue control routines and manual controls by two operator. But, due payment latency, system paused the certificate issuing. 
The payment is completed on March, 14th and the certificate was issued with approved data on Feb, 16th. The approved data covers a validity date over 825 days.
The solution is that the pre-issue control done by system must be done just before issuing certificate again.
To avoid the problem all other waiting certificates application are controlled and the existing pre-issue validation controls are applied just before issuing the certificate.

For Missing LocalityName or stateOrProvience:
The problem is small bug in our application verification and approval system. In a very special case, it could pass the Locality existence check. This was faced 2 times and one is the reported certificate. The problem is fixed, tested, put in production.

For keyggreement usage:
The keyagreement flag for Server SSL certificate profiles in our systems are set at the beginning, even before the Baseline Requirement first release. During our controls for checking compliances with standards includes BaseLine Requirements, we did not face a restriction for this keyusage. There is no restriction are seen for this keyusage. On Baseline Requirements section 7.1.2.4, there is a restriction for only keyCertSign and cRLSign flags. In RFC 5280, section 4.2.1.12, for server authentication certificates this is not restricted, even it was said that it can be used. 
After getting the problem via Bugzilla, we removed the flag from profiles and fixed it.
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.

E-Tugra: All required measures are taken for now. The certificates are controlled by the system. These are enough for preventing the certificates with these measures.
In addition to the these, a post-issue controls done by system will be extended will be extended with these restriction in 3-6 months.

Comment 6

[Wayne Thayer]

(In reply to Davut Tokgöz from comment #5)

Thank you for the updated incident report.

> For keyggreement usage:
> The keyagreement flag for Server SSL certificate profiles in our systems are
> set at the beginning, even before the Baseline Requirement first release.
> During our controls for checking compliances with standards includes
> BaseLine Requirements, we did not face a restriction for this keyusage.
> There is no restriction are seen for this keyusage. On Baseline Requirements
> section 7.1.2.4, there is a restriction for only keyCertSign and cRLSign
> flags. In RFC 5280, section 4.2.1.12, for server authentication certificates
> this is not restricted, even it was said that it can be used. 
> After getting the problem via Bugzilla, we removed the flag from profiles
> and fixed it.

RFC 5280 section 4.2.1.3 references RFC 3279, which specified allowed key usages for RSA keys in section 2.3.1.

> 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.
> 
> E-Tugra: All required measures are taken for now. The certificates are
> controlled by the system. These are enough for preventing the certificates
> with these measures.
> In addition to the these, a post-issue controls done by system will be
> extended will be extended with these restriction in 3-6 months.

I believe this satisfies all the required actions. Marking this resolved.