As others have noted the 5-day timeline should have started when identification of non-compliance started. The incident report notes that: >Non-compliance end date: 2025-06-23 Which seems to be based on when revocation would occur, not when the certificate profile was fixed (2025-06-18 according to the report). The related incident section is empty, which is strange as there are countless incidents from the past two years of these kinds of errors. CAs are expected to follow these incidents to understand what others did wrong, and how they can avoid similar issues. On glancing at certificates the CA has issued I note the intermediary being used 'a-sign-SSL-07': https://search.censys.io/certificates/789e625ae7bf6b604df93ca8eb99a30b0378a8f82a67562c66d8013926121529 I am interested in how you managed to configure your infrastructure to produce Subject Key IDs short enough to violate RFC 5280. I haven't seen that one before, and does mean that all certificates are still violating it - including ones issued today. Given this intermediary was produced in 2018 and it hasn't been noticed yet, perhaps a new auditor is in order. The CCADB records for the audits all need the Audit Statement Date, Period Start Date and Period End Date updated. I do wish to note that while the audit mentions the baseline requirements are to be considered, it only cover ETSI policy. There are more parts of CCADB that need updated too, but let's not dwell on it. The CCADB records note the following for 'Certificate Practice & Policy Statement': https://www.a-trust.at/downloads/Downloads/Certificate%20Practice%20Statement/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf This is listed as version 2.5, dated: 2024-08-29. Although the CCADB notes 2023-03-27 as the last updated date. This is found on the website under 'downloads' for 'a-sign-ssl-ev'. The version history implies a non-yearly update cadence, which I hope is improved going forward. The OID listed for this CPS is: 1.2.40.0.17.2.22. Yet the OID for the policy included in [a certificate issued today](https://search.censys.io/certificates/8818b72119cffe284184447d8f5e11d7439616534c77d4a3c2945846b983b707) ends in 0.17.1.20. This seems to correspond to a 'a.sign premium mobile' qualified certificate held in a different cps: https://www.a-trust.at/downloads/de/Certificate%20Practice%20Statement/a-sign-qualified/a-sign-qualified_cps.pdf Strictly speaking .040. and .40. are not byte-for-byte identical OIDs, but let's not dwell on that. Moving back to the listed CPS in CCADB: 1.5.2 only lists a physical address as a contact method, and no method for handling a certificate problem report. The website does mention a revocation service that is available over the phone Mon-Fri 10am - 6pm. There is also an email address listed on CCADB that is the general support address. 2.3 notes that the CPS is updated "at least on an annual basis". This is not reflected in the version history, but is perhaps aspirational. The rest of the CPS also seems aspirational, but does mention a 24x7 revocation service in 4.9.5? There is no mention of the revocation time periods, and the list of revocation reasons is also lacking. 4.10.1 notes: >Certicate status information can be obtained via CRL and OCSP. Expired certicates remain on the CRL, by the extension ExpiredCertsOnCRL. >CRLs are archived for thirty years after expiration. Which presumably means that revoked certs are held nigh-indefinitely on the CRL rather than being pruned when they expire. 7.1.2 notes that: >The subordinate CA is using id-kp-serverAuth and id-kp-clientAuth as extkeyUsage. Given that the subordinate CA is the intermediary, it is not, however subscriber certificates are using that extkeyUsage. 'qc-Statement' is also listed as present in subscriber certificates. It is not. There will be more issues than that, but a glance at an example certificate and the policy brought up those issues. I strongly recommend restarting a large amount of your practices from scratch if inclusion in root programs in intended in the near future.
Bug 1972887 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As others have noted the 5-day timeline should have started when identification of non-compliance started. The incident report notes that: >Non-compliance end date: 2025-06-23 Which seems to be based on when revocation would occur, not when the certificate profile was fixed (2025-06-18 according to the report). The related incident section is empty, which is strange as there are countless incidents from the past two years of these kinds of errors. CAs are expected to follow these incidents to understand what others did wrong, and how they can avoid similar issues. On glancing at certificates the CA has issued I note the intermediary being used 'a-sign-SSL-07': https://search.censys.io/certificates/789e625ae7bf6b604df93ca8eb99a30b0378a8f82a67562c66d8013926121529 I am interested in how you managed to configure your infrastructure to produce Subject Key IDs short enough to violate RFC 5280. I haven't seen that one before, and does mean that all certificates are still violating it - including ones issued today. Given this intermediary was produced in 2018 and it hasn't been noticed yet, perhaps a new auditor is in order. The CCADB records for the audits all need the Audit Statement Date, Period Start Date and Period End Date updated. I do wish to note that while the audit mentions the baseline requirements are to be considered, it only cover ETSI policy. There are more parts of CCADB that need updated too, but let's not dwell on it. The CCADB records note the following for 'Certificate Practice & Policy Statement': https://www.a-trust.at/downloads/Downloads/Certificate%20Practice%20Statement/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf This is listed as version 2.5, dated: 2024-08-29. Although the CCADB notes 2023-03-27 as the last updated date. This is found on the website under 'downloads' for 'a-sign-ssl-ev'. The version history implies a non-yearly update cadence, which I hope is improved going forward. The OID listed for this CPS is: 1.2.40.0.17.2.22. Yet the OID for the policy included in [a certificate issued today](https://search.censys.io/certificates/8818b72119cffe284184447d8f5e11d7439616534c77d4a3c2945846b983b707) ends in 0.17.1.20. This seems to correspond to a 'a.sign premium mobile' qualified certificate held in a different cps: https://www.a-trust.at/downloads/de/Certificate%20Practice%20Statement/a-sign-qualified/a-sign-qualified_cps.pdf Strictly speaking .040. and .40. are not byte-for-byte identical OIDs, but let's not dwell on that. Moving back to the listed CPS in CCADB: 1.5.2 only lists a physical address as a contact method, and no method for handling a certificate problem report. The website does mention a revocation service that is available over the phone Mon-Fri 10am - 6pm. There is also an email address listed on CCADB that is the general support address. 2.3 notes that the CPS is updated "at least on an annual basis". This is not reflected in the version history, but is perhaps aspirational. The rest of the CPS also seems aspirational, but does mention a 24x7 revocation service in 4.9.5? There is no mention of the revocation time periods, and the list of revocation reasons is also lacking. 4.10.1 notes: >Certicate status information can be obtained via CRL and OCSP. Expired certicates remain on the CRL, by the extension ExpiredCertsOnCRL. >CRLs are archived for thirty years after expiration. Which presumably means that revoked certs are held nigh-indefinitely on the CRL rather than being pruned when they expire. 7.1.2 notes that: >The subordinate CA is using id-kp-serverAuth and id-kp-clientAuth as extkeyUsage. Given that the subordinate CA is the intermediary, it is not, however subscriber certificates are using that extkeyUsage. 'qc-Statement' is also listed as present in subscriber certificates. It is not. There will be more issues than that, but a glance at an example certificate and the policy brought up those issues. I strongly recommend restarting a large amount of your practices from scratch if inclusion in root programs is intended in the near future.