CA Responses to March 2016 CA Communication

AC Camerfirma, S.A.

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Feb 15
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2019 Feb 15
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (e) We use SHA-1 signing in some other way. (d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.d) We use SHA1 EE certificates for SMIME and client authentication. We issue those certificates in some spanish public organizations that wasn't able to change their tecnology in time. We change this along 2016. e) We use SHA-1 in some TSA services responses. We are moving our customers to SHA256 along this 2016 year.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.(e) We use PrintableString in DN, but BMPString is forced by the application when special characters are found. 200 certificates affected. We are still fixing the problem. We plan to have a solution in a couple of months and make a substitution plan.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.Chambers of Commerce Root will be fully migrated to Chambers of Commerce Root - 2016 by 2020 Chambers of Commerce Root - 2008 will be fully migrated to Chambers of Commerce Root - 2016 by 2020 Global Chambersign Root will be fully migrated to Global Chambersign Root - 2016 by 2020 Global Chambersign Root - 2008 will be fully migrated to Global Chambersign Root - 2016 by 2020
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Actalis

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Jul 7
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We accept Certificate Signing Requests (CSRs) signed with SHA-1.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Amazon Trust Services

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.Amazon assumed operation of the Starfield Services Root Certificate Authority - G2 on June 10, 2015. Our CPS was updated at such time and audit opinions have been issued for the examination period including the transfer.

Asseco Data Systems S.A. (previously Unizeto Certum)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 30
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2018 Jan 6
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (e) We use SHA-1 signing in some other way. (d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We use the SHA-1 certificates for S/MIME and client authentication We use the SHA-1 to sign CRLs that correspond to SHA-1 certificates
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has been a change in ownership of our PKI. Now, we provide our services under the new name which is: Asseco Data System S.A. The annual audit is on track. CP/CPS documents have been updated and published at: https://www.certum.eu/certum/179898.xml

Atos

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 15
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(d) Subject CN name information (if present) does not have a corresponding iPAddress or dNSName entry in the subjectAltName extension. Workaround to be removed in Bug #1245280.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.d) count: 1 certificate created/valid from 12/21/2015 to 12/21/2016
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Autoridad de Certificacion Firmaprofesional

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 May 19
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Nov 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We still sign SHA­1 certificates for natural and legal person, pursuant eIDAS (REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL, of 23 July 2014, on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC). We do not sign any TLS/SSL SHA­1 certificates. We plan to stop signing/issuing any kind of certificate or certificate status information by December the 1st. Spanish regulation force to all Spanish TSP to stop issuing end entity certificates of any type before January the 1st, 2017.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 29
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 29
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(d) Subject CN name information (if present) does not have a corresponding iPAddress or dNSName entry in the subjectAltName extension. Workaround to be removed in Bug #1245280.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.Although we had answered (c) and (d) in the 2015 Communication, a thorough study reveals that we have never been in the (c) situation, indeed, EJBCA does not allow the combination of ca:False and inclusion of pathLenConstraint. We have audit some certificates, old and new ones and they do not include pathLenConstraint. The mistake is due to how Microsoft certificate visor interprets the absence of this field. On the other hand there are 115 with (d) issue that will be revoked by July, the 1st, 2016
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Buypass

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 23
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 23
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.Issuer: CN = Buypass Class 2 CA 1, O = Buypass AS-983163327, C = NO Subject: CN = Buypass Class 2 CA 1, O = Buypass AS-983163327, C = NO SHA-1 Fingerprint: a0a1ab90c9fc847b3b1261e8977d5fd32261d3cc SHA-256 Fingerprint: 0f4e9cdd264b025550d170806340214fe94434c9b02f697ec710fc5feafb5e38 Date: 10/13/2016
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Certicámara

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Feb 29
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.Certicamara ROOT CA and subsequent SUB CA's does not issue SSL/TLS certificate. However as of February 29 we stopped issuing all SHA1 certificates, and a new ROOT CA with SHA2 will be issued after May 6 2016.
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2018 Jan 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We are using SHA1 certificates to sign TSA responses. We do, however have a plan to migrate those certs to SHA2.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.We have the following root CN = AC Raíz Certicámara S.A. O = Sociedad Cameral de Certificación Digital - Certicámara S.A. C = CO But plan to create a new one to SHA2 in may 2016, we should finish migrating all users in December 2018.
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Certinomis / Docapost

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Jan 27
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.PKI SHA2 : 04/01/2016 (never issued SHA1) PKI SHA1 : 01/27/2015 we have stopped this CA on 06/18/2015.
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Jan 27
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.PKI SHA2 : 04/01/2016 (never issued SHA1) PKI SHA1 : 10/12/2016
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.PKI SHA1: the PKI has been stop on 06/18/2015 but we still use the CA key to sign SHA1 CRL till the end of validity of the intermediate CA : 12/12/2018 as there is no more valid cert, we could stop issuing SHA1 CRL....
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

China Financial Certification Authority (CFCA)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.We have NO SHA-1 root included in Mozilla. That is : we never issue SHA-1 certificate with root included in Mozilla
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.We have NO SHA-1 root included in Mozilla. That is : we never issue SHA-1 certificate with root included in Mozilla
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We are using SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. and we are upgrading it to SHA256.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

China Internet Network Information Center (CNNIC)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 4
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Dec 4
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.CNNIC have 2 root certificates included in Mozilla CA program, CNNIC Root and CNNIC EV Root. From Jan 28th 2015, CNNIC issue SHA256 OV certificates and stop issue SHA1 OV certificate. The DV and EV are still using SHA1. CNNIC stop issuing SHA1 certificate by the end of 2015. We plan to upgrade device and software and also deploy new SHA 256 intermediate Root (operated by CNNIC ) to issue SHA256 DV and EV cert by the end of May, 2016.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.None
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Chunghwa Telecom

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2018 Feb 6
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.We still have 16 TLS/SSL certificates that we have communicated to those customers that we can offer them new SHA 256 SSL certificates to replace their original SHA-1 SSL certificates without extra charge, but they have not yet agreed to replace. We plan to communicate with them again this year. And we plan to revoke those certificates before 2016-12-31.
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 22
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

ComSign

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We use the SHA-1 algorithm to periodically generate and sign CRL by the two Root CAs and by some Sub CAs under these roots. The CRLs are distributed as plain files on our public web servers. No signing operations take place by any server except for the CA servers themselves.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Sep 30
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Sep 30
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(d) We use SHA-1 to sign certificates. (b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.We will be issuing signatures and identification certificates for individuals and applications until 31/12/2016 when all end-entity and infraestructure certificates will be issued in Sha-2 from then on.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.All of our certificates containing non printablestring characters is issued with teletextstring. The last one of them was issued by 30/9/2015. Therefore the last one will expire by 30/9/2019.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.We do have undercome "Physical Relocation" and transfer the "Operation of the PKI to a different organization that is already operating root certificates included in Mozilla’s program". Our systems and operation its been transferred completely to Firmaprofesional by 15/4/2016. This relocation and operations transmission has been audited and documented. None of these changes have required to update our CP/CPS documents or audit statements.

Cybertrust Japan / JCSI

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.We have never issued SHA-1 TLS/SSL certificates yet after the root was transferred from JCSI Inc. to us at July 2014.
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

D-TRUST

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Dhimyotis / Certigna

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

DigiCert

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Mar 30
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.Test certificate issued by DnB NOR ASA PKI Class G, which chains to the Baltimore Cybertrust Root through the Eurida Primary CA.
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2021 Jan 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(c) We use SHA-1 to sign OCSP responses, directly under a CA certificate.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.SHA-1 is used only to sign OCSP Responses for certificates signed using SHA-1.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Disig, a.s.

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Jul 30
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Feb 16
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

DocuSign (OpenTrust/Keynectis)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2018 Dec 18
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (e) We use SHA-1 signing in some other way. (d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.* (d) some OCSP responder certificates are SHA1-signed. This will end on 12/31/2016, at the latest * (e) some CRLs are SHA1-signed. This will end on 12/31/2016, at the latest * in the two previous cases, the signatures are not computed on any externally provided data, so a chosen-prefix collision attack is not possible
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.As of 31st of March 2016, 10755 certificates are concerned by (e). Last issuance date will be 06/30/2016. Last expiration date will be 06/30/2019.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.A change in Legal Ownership has occurred in November 2015, all related CP/CPS documents have been modified accordingly to reflect the new owner’s name), POO informations have been transmitted to Mozilla in November 2015. No CA private key was necessary, HSMs stay in the same location, operated by the same personnel, under identical controls.

E-Tugra

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2014 Oct 15
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Aug 14
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.The following root will be expire on 08/14/2016. After that date, it can be removed. Subject/Issuer: EBG Elektronik Sertifika Hizmet Sağlayıcısı Vald To: 08/14/2016 SHA1 Fingerprint: ‎8c 96 ba eb dd 2b 07 07 48 ee 30 32 66 a0 f3 98 6e 7c ae 58
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

EDICOM

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Aug 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Aug 29
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(c) We use SHA-1 to sign OCSP responses, directly under a CA certificate.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.Our "ACEDICOM Root" sign OCSP responses, using the nonce extension wich overcomes the reply atack.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 19
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 19
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Entrust

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2019 Mar 30
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.Not applicable
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.For item (e), there are approximately 5000 certificates with this issue. As item(e) has not been corrected, the last issuance date could be as late as 30 June 2016 with a maximum expiry time of 30 September 2019. When item (e) is corrected, this information can be updated.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

GlobalSign

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2019 May 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (e) We use SHA-1 signing in some other way. (d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.For (d), We use SHA-1 to sign Code Signing and S/MIME certificates, as required from our customers, - Code Signing: Windows Vista and Windows Server 2008 still need Kernel mode driver code signing to be SHA-1. - S/MIME: We will encourage customers to make their environments to support SHA-2, and to migrate to SHA-2, asap. We don’t have explicit end of issuing date now. We also use SHA1 to sign SHA1 CAs’ OCSP responder certs For (e), we create CRLs of SHA1 CAs.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.For (e), we do include character encoding other than PrintableString and UTF8 in DN fields. Specifically, we still allow Teletext String in the CN if the user asks for a CN encoded this way. We may also encode other DN fields with Teletext String. We posted a comment in Bugzilla asking for more info: https://bugzilla.mozilla.org/show_bug.cgi?id=1256071
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

GoDaddy

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2021 May 9
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (e) We use SHA-1 signing in some other way. (d) We use SHA-1 to sign certificates.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.(d) We are still issuing subscriber code signing certificates from our SHA-1 chains. We have not set a date at which we will stop issuing these certificates. We plan to adhere to Mozilla, Microsoft, and CA/Browser forum policies. We include 64 bits of entropy in the serialNumber field. (e) We use SHA-1 to sign CRLs that correspond to SHA-1 certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(b) DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround to be removed in Bug #989518.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.There are 335,000 unexpired, unrevoked certificates with problem (b). The last of these expires on 5/9/2021; however, the last signed with SHA-2 expires 5/1/2019.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.Starfield transferred the Starfield Services G2 root CA to Amazon Web Services, Inc. on June 10, 2015. Amazon has previously supplied the requested information to Mozilla.

Government of France (ANSSI, DCSSI)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(d) We use SHA-1 to sign certificates. (e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.Certificates signed by the root certificate IGC/A are CA certificates able to issue certificates for ministries' agents (identification, signature, encryption) as well as server certificates (SSL/TLS). These certificates will be in use until December 31st 2016. Ministries are currently in the process of renewing their certificates with an alternate solution (through an interministerial market with an external trust service provider). Measures currently in place are : (1) revocation of the certificate in case there is a compromise or a suspected compromise and (2) a compulsory migration measure of all SHA-1 certificates to SHA-2 certificates before the end of 2016.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.The migration to new certificates will be effective on December 31st 2016. Only the root certificate (IGC/A, registered in the Mozilla Firefox browser) will be removed from the Mozilla's CA Certificate Program.
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has been not change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of Hong Kong (SAR), Hongkong Post, Certizen

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Dec 3
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.At the moment, there are only a few certificates that are valid beyond Jan 1, 2017. We plan to have them revoked by 31 Dec 2016.
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(d) We use SHA-1 to sign certificates. (e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.(d) We use SHA-1 to sign certificates - Our root certificate has issued one SHA-1 sub CA, which also issues SHA-1 client authentication certificates for S/MIME and PDF document signing and user authentication to legacy systems. (e) We use SHA-1 signing in some other way - Our root certificate and that SHA-1 sub CA also sign CRLs with SHA-1 signatures. There is no third party who possesses any certificate of our root certificate capable of issuance of digital certificates. We plan to commence migration of such certificates along with our root certificate rollover to a new SHA-256 PKI structure as soon as possible, and no later than end of 2018.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(d) Subject CN name information (if present) does not have a corresponding iPAddress or dNSName entry in the subjectAltName extension. Workaround to be removed in Bug #1245280.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.Will stop issuing SSL certificates without the DNSName entry in the subjectAltName extension on 1 Sep 2016.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been any change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of Japan, Ministry of Internal Affairs and Communications

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2013 Oct 31
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Mar 31
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.Currently, we are migrating from SHA-1 to SHA-2. Estimated completion date is 2017-3-31.
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2017 Mar 31
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.Currently, we are migrating from SHA-1 to SHA-2. Estimated completion date is 2017-3-31.
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2014 Dec 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Jan 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 4
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.Yes, We have a old root CA that could be removed at january 2017 (finish migration). The certificate data are: Subject: CN = Root CA Generalitat Valenciana OU = PKIGVA O = Generalitat Valenciana C = ES SHA1 Fingerprint: A0:73:E5:C5:BD:43:61:0D:86:4C:21:13:0A:85:58:57:CC:9C:EA:46 SHA256 Fingerprint: 8C:4E:DF:D0:43:48:F3:22:96:9E:7E:29:A4:CD:4D:CA:00:46:55:06:1C:16:E1:B0:76:42:2E:F3:42:AD:63:0E
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of Taiwan, Government Root Certification Authority (GRCA)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2013 Mar 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 May 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 May 31
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 May 31
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of The Netherlands, PKIoverheid (Logius)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.Under the currently included roots PKIoverheid has never issued SHA-1 certicates. In a previously included root (“Staat der Nederlanden Root CA”) this was the case, but this root has been removed from the Mozilla CA Certificate Program (expired in December 2015).
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.See previous statement.
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(b) DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround to be removed in Bug #989518.
Action
Response
ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.The use of the basic constraint extension in end entity certificates is allowed as an optional value in our system per RFC 5280 section 4.2.1.9. Several of our (externally operated) subCA’s have included this value in their end entity certificates. We are currently investigating the amount of certificates concerned, We are in the process of altering our CP with regard to this issue. Our new CP will be effective coming July.
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 17
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 17
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.We have one root certificate called "TÜBİTAK UEKAE Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3" included in Mozilla's CA Certificate Program. It has an expire date at ‎21 .08 . 2017 . Nowadays, we have a new root request with Bug Report #1262809.
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

HARICA

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2017 Mar 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 6
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 6
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.HARICA expects the two ROOT CAs issued in 2015 and approved by Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1256494) to be propagated to Application Software Suppliers. This process is not under HARICA's control. As soon as the new Roots are propagated, the current Root (2011) will be phased-out. When all end-entity certificates expire or become revoked, the old Root will be decommissioned.
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

IdenTrust Services, LLC

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Dec 14
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (d) We use SHA-1 to sign certificates. (e) We use SHA-1 signing in some other way.
Action
Response
ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.IdenTrust issues SHA-1 S/MIME Client Authentication certificates and some device certificates (not TLS). CRLs and OCSP responses associated to those certificates are signed using the SHA-1 algorithm. IdenTrust is progressively migrating those customers to another SHA-256 root included in the Mozilla program. The migration is driven by expiration of intermediate certificates issuing those certificates, an no intermediate expires beyond 2019. All certificates signed with SHA-1 algorithm include serial numbers with 20+ bits of entropy. All OCSP responders are under the delegated model.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Jun 30
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.CN = DST ACES CA X6 OU = DST ACES O = Digital Signature Trust C = US Removal date: After November 21, 2017 SHA-1 Fingerprint: 40:54:DA:6F:1C:3F:40:74:AC:ED:0F:EC:CD:DB:79:D1:53:FB:90:1D SHA-256 Fingerprint: 76:7C:95:5A:76:41:2C:89:AF:68:8E:90:A1:C7:0F:55:6C:FD:6B:60:25:DB:EA:10:41:6D:7E:B6:83:1F:8C:40
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.IdenTrust Services LLC, owns and operates all the roots included in the Mozilla program. This includes two root previously owned by Digital Signature Trust. IdenTrust Services LLC. Is a subsidiary of HID Global. There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Izenpe S.A.

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2014 Mar 5
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Jun 30
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Krajowa Izba Rozliczeniowa S.A. (KIR)

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Apr 1
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 1
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

Microsec Ltd.

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Oct 7
Action
Response
ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.This certificate expired on the 11/30/2015
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Oct 17
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY)2016 Apr 22
Action
Response
ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY) The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016.2016 Apr 1
Action
Response
ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully. Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016. The Bug Numbers below refer to Bugzilla Bugs.(i) None of the above
Action
Response
ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.None
Action
Response
ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
Action
Response
ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.

NetLock Ltd.

 
Action
Response
ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016.2015 Nov 14
Action
Response
ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016. As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program.2016 Dec 31
Action
Response
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
Action
Response
ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have