Closed Bug 1567062 Opened 2 months ago Closed Last month

Asseco DS / Certum: inconsistent disclosure of externally-operated intermediate


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: agwa-bugs, Assigned: wtrapczynski)


(Whiteboard: [ca-compliance])

Asseco has disclosed the following intermediate as being operated under the same CP/CPS as parent:

However, the same subject + SPKI is found in this root certificate, which has a different CP/CPS:

Ever confirmed: true
Assignee: wthayer → wtrapczynski
Whiteboard: [ca-compliance]

Thank you for reporting this. As it was described in [1] this case is not as obvious as it might seem. We will inspect it and we will share our point of view soon.


I apologise for the delay in response. We need some more time to prepare explanation. We will have a response by August 1.

I'm concerned that it would take two weeks to provide an explanation for a policy violation; my own expectations had been response times in line with the Baseline Requirements' revocation timelines, to ensure prompt incident reporting.

While I'm tentatively accepting this proposed date, I think it would be to Asseco / Certum's benefit to ensure that, in the future, any Bugzilla issues are responded to with a preliminary incident report consistent with the timeframes set in Section 4.9.5 of the Baseline Requirements, even if the matter is a Policy violation and not a BR violation.

Whiteboard: [ca-compliance] → [ca-compliance] Next Update - 01-Aug 2019

This certificate was issued by Asseco as cross-certificate, and was signed by root certificate controlled by Asseco, and we disclosed it with audit information "Same As Parent".

We generated this certificate in September 2018 and it was not in scope of currently published audit statement which covered the period April 15, 2017 to March 26, 2018. This certificate will be show up in the new audit statement which covered the period March 27, 2018 to 4 March, 2019. The new audit statement will be delivered to Mozilla immediately after we received it [1].


Thanks for the update!

I'm a bit confused, as the same SPKI is being reported as two different organizations' CP/CPSes. The information in Comment #4 leaves me slightly confused as to who is in operational control of the key material, so I'm hoping you can clarify this. Does Asseco/Certum control the key, or does

Flags: needinfo?(wtrapczynski)

The key of signing root certificate is controlled by Asseco, SPKI: 08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7.
The key of cross-certified root certificate is controlled by, SPKI: DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59.

Flags: needinfo?(wtrapczynski)

Thanks for the information. To be clear, this bug concerns the SPKI with keyid DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59. This is the SPKI of the two certificates in my original report, and is currently being reported as operating under two different organizations' CP/CPSes.'s disclosure says that this SPKI is operating under's CP/CPS, which appears to be correct based on Comment #6.

Asseco's "same as parent" disclosure means that Asseco is reporting that this SPKI is operating under Asseco's CP/CPS, which appears to be incorrect based on Comment #6.

When CAs disclose cross-certificates in CCADB, they are supposed to disclose the audit/CP/CPS information of the subject. Has Asseco disclosed information about the issuer instead?

Flags: needinfo?(wtrapczynski)

Yes, we disclosed audit/CP/CPS information of the issuer. This certificate was issued by our root certificate and we assumed that by ticking "same as parent" we assert that was created and is managed in accordance with our audit/CP/CPS information.

Peter Bowen's comment to the m.d.s.p. discussion [1] pointed out the possibilities of improving the CCADB. We think that is reasonable idea.


Flags: needinfo?(wtrapczynski)

I direct your attention to Wayne Thayer's followup email in which he said:

I think we want to continue to hold the issuing CA accountable for disclosing any cross-certificates it signs, but they need to indicate that the audit and applicable CP/CPS is that of the subject CA when that is the case.

He also requested that CAs fix issues reported by "as soon as possible."

Although improvements to the CCADB might be warranted, they are not required for Asseco to fix this disclosure.

As part of the remediation for this issue, I think it would be a good idea for Asseco to review all intermediate certificates signed by an Asseco-operated CA (not just those flagged by for accurate disclosure, and to report any further corrections here, as has been requested of other CAs.

Flags: needinfo?(wtrapczynski)
Summary: Asseco / inconsistent disclosure of externally-operated intermediate → Asseco: inconsistent disclosure of externally-operated intermediate

We fixed issues reported by We set subject audit/CP/CPS information instead of issuer for these certificates:

  • keyid: DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59 ([1] - for this ertificate is still showing inconsistent audit details but now is probably the result of lack of EV audit for this certificate [2] in CCADB)
  • keyid: F9:60:BB:D4:E3:D5:34:F6:B8:F5:06:80:25:A7:73:DB:46:69:A8:9E ([3] - this is the second cross-certificate for

Additionally, we will review all intermediate certificates next week. I will keep you informed.


Flags: needinfo?(wtrapczynski)

We reviewed all our non-expired and non-revoked intermediate certificates and we did not find any additional inconsistency in audit/CP/CPS information.

It appears that all questions have been answered and remediation is complete.

Closed: Last month
Resolution: --- → FIXED
Whiteboard: [ca-compliance] Next Update - 01-Aug 2019 → [ca-compliance]
Summary: Asseco: inconsistent disclosure of externally-operated intermediate → Asseco DS / Certum: inconsistent disclosure of externally-operated intermediate
You need to log in before you can comment on or make changes to this bug.