CA/PROCERT Issues: Difference between revisions

Jump to navigation Jump to search

CA/PROCERT Issues (view source)

Revision as of 13:13, 18 September 2017

9,212 bytes added ,  18 September 2017
Add PROCERT responses and some Mozilla responses
(Strike Issue Q)
(Add PROCERT responses and some Mozilla responses)
Line 10: Line 10:


This issue was reported to PROCERT on 7th August by email, and 16th August by bug report. This particular certificate was issued in Dec 2016 and was revoked on 11th August.
This issue was reported to PROCERT on 7th August by email, and 16th August by bug report. This particular certificate was issued in Dec 2016 and was revoked on 11th August.
===PROCERT Response===


PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c1 initially claimed] that this was entirely RFC-compliant, a claim [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c3 comprehensively rebutted] by Ryan Sleevi.
PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c1 initially claimed] that this was entirely RFC-compliant, a claim [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c3 comprehensively rebutted] by Ryan Sleevi.
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ then said]: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. We completed those actions in this point."


==Issue E: Issuance of 1024-bit Certificate (December 2016)==
==Issue E: Issuance of 1024-bit Certificate (December 2016)==


[https://crt.sh/?id=197068798&opt=cablint This certificate], issued on Dec 12 2016 for the purposes of OCSP signing, contains a 1024-bit key. PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c16 claimed] that they have not issued certs with 1024-bit keys since 2010; once this example was pointed out, they corrected that to say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c19 for end users]". They have been asked whether they have issued any more certs with 1024-bit keys for any purpose, but have not yet responded.   
[https://crt.sh/?id=197068798&opt=cablint This certificate], issued on Dec 12 2016 for the purposes of OCSP signing, contains a 1024-bit key. PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c16 claimed] that they have not issued certs with 1024-bit keys since 2010; once this example was pointed out, they corrected that to say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c19 for end users]". They have been asked whether they have issued any more certs with 1024-bit keys for any purpose, but have not yet responded.   
===PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate in 2048, supporting into the installation process. We completed those actions in this point." They also said: "A deadline has been set until the 14th of this month to revoke and re-issue certificates with problems."
===Further Comments===
According to crt.sh, contrary to PROCERT's assertions, this certificate has still not been revoked as of 2017-09-18. And we are not sure who they are referring to when they say "the client", as this was a certificate for PROCERT's internal use for signing OCSP responses.


==Issue G: Internal IP Address in SAN (March 2015 - March 2017)==
==Issue G: Internal IP Address in SAN (March 2015 - March 2017)==
Line 24: Line 36:


[https://crt.sh/?id=10632924 This certificate] also has an IP address value in the CN and SAN which is an internal IP address: 10.79.6.100. While this cert has now expired, the notAfter date is later than the latest permitted notAfter date in the BRs for issuing certs with internal IPs, which was 1 Nov 2015.
[https://crt.sh/?id=10632924 This certificate] also has an IP address value in the CN and SAN which is an internal IP address: 10.79.6.100. While this cert has now expired, the notAfter date is later than the latest permitted notAfter date in the BRs for issuing certs with internal IPs, which was 1 Nov 2015.
===PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. We completed those actions in this point."


==Issue I: CN Not Also In SAN (March 2016 - June 2017)==
==Issue I: CN Not Also In SAN (March 2016 - June 2017)==
Line 36: Line 52:


There are a total of [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=25 11 certificates] with this problem.
There are a total of [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=25 11 certificates] with this problem.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. We completed those actions in this point."


==Issue J: Use of keyCertSign in Leaf Certificates (October 2016 - June 2017)==
==Issue J: Use of keyCertSign in Leaf Certificates (October 2016 - June 2017)==


[https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&cablint=782 24 PROCERT certificates] have the Certificate Sign key usage bit set, but are leaf certificates. This is in contravention of the BRs 7.1.2.3 e).
[https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&cablint=782 24 PROCERT certificates] have the Certificate Sign key usage bit set, but are leaf certificates. This is in contravention of the BRs 7.1.2.3 e).
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "The template for this certificate was fixed and based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. We completed those actions in this point."


==Issue K: Internal DNS Names in Certificates (May - June 2017)==
==Issue K: Internal DNS Names in Certificates (May - June 2017)==
Line 48: Line 72:


[https://crt.sh/?id=197158298&opt=cablint This certificate] and [https://crt.sh/?id=197347297&opt=cablint this certificate] and [https://crt.sh/?id=197347294&opt=cablint this certificate] and [https://crt.sh/?id=197347292&opt=cablint this certificate] also have an unqualified DNS name in the SAN, "OWASERVER", and the first of those is not revoked.
[https://crt.sh/?id=197158298&opt=cablint This certificate] and [https://crt.sh/?id=197347297&opt=cablint this certificate] and [https://crt.sh/?id=197347294&opt=cablint this certificate] and [https://crt.sh/?id=197347292&opt=cablint this certificate] also have an unqualified DNS name in the SAN, "OWASERVER", and the first of those is not revoked.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. We completed those actions in this point."


==Issue L: helloburgershack.com (June - July 2017)==
==Issue L: helloburgershack.com (June - July 2017)==
Line 56: Line 84:


We would be interested to know the sequence of events which led to this succession of certificate issuances.
We would be interested to know the sequence of events which led to this succession of certificate issuances.
===PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said] on Friday 8th September: "Based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process. This client provides a production window after the next Tuesday [12th September] in order to proceed with the revoke and the reissue of the certificate. Pending action." They also said: "A deadline has been set until the 14th of this month to revoke and re-issue certificates with problems."
===Further Comments===
The fifth certificate, with typos, is still not revoked as of Monday 18th September.


==Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)==
==Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)==
Line 62: Line 98:


However, neither PROCERT's [https://www.procert.net.ve/documentos/AC-D-0011.pdf CP] nor [https://www.procert.net.ve/documentos/AC-D-0003.pdf CPS] is in RFC 3647 or RFC 2527 format.
However, neither PROCERT's [https://www.procert.net.ve/documentos/AC-D-0011.pdf CP] nor [https://www.procert.net.ve/documentos/AC-D-0003.pdf CPS] is in RFC 3647 or RFC 2527 format.
===PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "After a validation process, we modify the RFC number in our documentation. We complete this point."
===Further Comments===
We believe PROCERT has misunderstood this issue. The issue here is not that some RFC number in the document is wrong, but that the document is not arranged according
to the layout given in RFC3647. To fix this would require completely rearranging the document, which we have seen no evidence that PROCERT have done.


==Issue N: otherNames in Certificate SAN (2011 - August 2017)==
==Issue N: otherNames in Certificate SAN (2011 - August 2017)==
Line 72: Line 117:


This issue was reported to PROCERT on 13th August by email, and 16th August by bug report. The particular sample certificate was issued in May 2017 and is still not revoked as of 28th August.
This issue was reported to PROCERT on 13th August by email, and 16th August by bug report. The particular sample certificate was issued in May 2017 and is still not revoked as of 28th August.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internal testing and validation, we contact the customer, request a window to generate a new CSR and review and reissue the certificate, we will also support the installation process. We keep in touch with customers with active SSL to proceed with this point. We advance as much as possible with customers. Some of these certificates have expired. For the issue of new certificates, verify the observations contained in the number V."


==Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - August 2017)==
==Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - August 2017)==
Line 80: Line 129:


Initially, PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c9 claimed] that everything was fine because their responder returned the correct response for existing certificates and, [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c12 later], that it returned "unauthorized" when asked about a certificate PROCERT had not issued. But it has been clearly demonstrated that for unknown certificates where the request claims PROCERT is the issuer, the response is incorrect.
Initially, PROCERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c9 claimed] that everything was fine because their responder returned the correct response for existing certificates and, [https://bugzilla.mozilla.org/show_bug.cgi?id=1391058#c12 later], that it returned "unauthorized" when asked about a certificate PROCERT had not issued. But it has been clearly demonstrated that for unknown certificates where the request claims PROCERT is the issuer, the response is incorrect.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ gave the following statement]:
<blockquote>
As we explained into Mozilla Bug ({{bug|1391058}}), when we applied the Microsoft tool, the system shows this message “In the Value data box, type the path to the directory you created in step 3 of the directory structure procedure and that contains the issued serial numbers, and then click OK.”.
We refresh or restart the service, then, the OSCP registry is automatically deleted. For testing we use different versions of Windows Server (2008, 2012 and 2016) all the versions present the same result. Additionally we ask for an answer at Microsoft TechNet please https://social.technet.microsoft.com/Forums/windowsserver/es-ES/981f6e48-dc25-4eeb-a1d6-0bc72b9b4fc9/ocsp-online-responder-service-assume-a-certificate-that-is-not-included-in-the-crl-as-a-valid-and?forum=winserversecurity
Now we stay contacting Microsoft in order to obtain and adequate procedure or batch. In paralleled we work in our own OCSP software.
</blockquote>


==Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)==
==Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)==


PROCERT OCSP responses are signed with SHA-1 and, since they reflect an attacker-controlled serial number, is vulnerable to a chosen prefix attack. This is not formally against documented policy but in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 April 2017 CA Communication], PROCERT affirmed that "SHA-1 certificates are no longer used in the infrastructure related to our root certificates included in Mozilla's CA Certificate Program. (e.g. SHA-1 is no longer used to sign OCSP responses)." They asserted something similar in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 March 2016 CA Communication]. However, this appears not to be true.
PROCERT OCSP responses are signed with SHA-1 and, since they reflect an attacker-controlled serial number, is vulnerable to a chosen prefix attack. This is not formally against documented policy but in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 April 2017 CA Communication], PROCERT affirmed that "SHA-1 certificates are no longer used in the infrastructure related to our root certificates included in Mozilla's CA Certificate Program. (e.g. SHA-1 is no longer used to sign OCSP responses)." They asserted something similar in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 March 2016 CA Communication]. However, this appears not to be true.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "We check the standard, the OCSP certificate is SHA 256, the answer in this case is an observation. We work to check and validate the adjust to SHA 256 in the OCSP answer. This situation does not contravene any standard."


==<strike>STRUCK: Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)</strike>==
==<strike>STRUCK: Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)</strike>==
Line 91: Line 156:
===PROCERT Response===
===PROCERT Response===


PROCERT noted that this certificate was not issued by PROCERT. On checking this turned out to be correct; it's issued by another part of the same Super-CA hierarchy, as are all the other 96 certificates found in the original search. So this issue has been struck. Apologies to PROCERT.
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ noted] that this certificate was not issued by PROCERT. On checking this turned out to be correct; it's issued by another part of the same Super-CA hierarchy, as are all the other 96 certificates found in the original search. So this issue has been struck. Apologies to PROCERT.


==Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 2015 - August 2017)==
==Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 2015 - August 2017)==


TeletexString is one (deprecated) way of encoding string values in a certificate. Lots of PROCERT certificates ([https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&cablint=217 1], [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=218 2], [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=229 3]) have got the encoding wrong. For example, [https://crt.sh/?id=197347377&opt=cablint This certificate] has an incorrectly encoded TeletexString in Certificate and in X520LocalityName. [https://crt.sh/?id=197347358&opt=cablint This certificate] uses an incorrectly-encoded TeletexString in X520OrganizationalUnitName, as do several other certificates. [https://crt.sh/?id=194225991&opt=cablint This certificate] is using TeletexString in the commonName, which is "*.movilnet.com.ve", so that seems unnecessary as no special characters are required, and it's not the case for most other PROCERT certs.
TeletexString is one (deprecated) way of encoding string values in a certificate. Lots of PROCERT certificates ([https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&cablint=217 1], [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=218 2], [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=229 3]) have got the encoding wrong. For example, [https://crt.sh/?id=197347377&opt=cablint This certificate] has an incorrectly encoded TeletexString in Certificate and in X520LocalityName. [https://crt.sh/?id=197347358&opt=cablint This certificate] uses an incorrectly-encoded TeletexString in X520OrganizationalUnitName, as do several other certificates. [https://crt.sh/?id=194225991&opt=cablint This certificate] is using TeletexString in the commonName, which is "*.movilnet.com.ve", so that seems unnecessary as no special characters are required, and it's not the case for most other PROCERT certs.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Based on internal testing and validation, we contact the customer, request a window to generate a new CSR and review and reissue the certificate, we will also support the installation process. We keep in touch with customers with active certificate to proceed with this point. We advance as much as possible with customers."


==Issue S: Non-Random Serial Numbers (September 2016 - August 2017)==
==Issue S: Non-Random Serial Numbers (September 2016 - August 2017)==


The BRs (section 7.1, since September 2016) and Mozilla Policy (section 5.2, since February 2017) require that every certificate contain at least 8 bytes (64 bits) of randomness in the serial number, as a preventative measure against hash algorithm weakness. Certificates currently issued by PROCERT, such as [https://crt.sh/?id=199512395 this example], seem to have serial numbers of the form of four leading bytes which are a time-based counter (measures in milliseconds), then zeroes, then a 2-byte incrementing per-cert counter. This practice is ongoing, although PROCERT [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 confirmed] in their response to Action 3 of the April 2017 CA Communication that they would conform to version 2.4.1 of the Mozilla Policy by June 1st, 2017. The question specifically mentioned the issue of 64-bits of randomness in serial numbers.
The BRs (section 7.1, since September 2016) and Mozilla Policy (section 5.2, since February 2017) require that every certificate contain at least 8 bytes (64 bits) of randomness in the serial number, as a preventative measure against hash algorithm weakness. Certificates currently issued by PROCERT, such as [https://crt.sh/?id=199512395 this example], seem to have serial numbers of the form of four leading bytes which are a time-based counter (measures in milliseconds), then zeroes, then a 2-byte incrementing per-cert counter. This practice is ongoing, although PROCERT [https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00022,Q00029 confirmed] in their response to Action 3 of the April 2017 CA Communication that they would conform to version 2.4.1 of the Mozilla Policy by June 1st, 2017. The question specifically mentioned the issue of 64-bits of randomness in serial numbers.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "We check the observation. Procert technical staff applied the observation and fix the system in this particular point."


==Issue T: Inappropriate Key Usage Value of "Key Agreement" (October 2016 - August 2017)==
==Issue T: Inappropriate Key Usage Value of "Key Agreement" (October 2016 - August 2017)==


[https://crt.sh/?id=197347381&opt=cablint,x509lint This certificate] and [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=734 21 others] all have a Key Usage of, among other things, "Key Agreement", which is inappropriate for an RSA public key. Many of these were revoked soon after they were issued. If the first ones were a problem, why was the problem not fixed? cablint marks this as an error, as it's a violation of [https://tools.ietf.org/html/rfc3279#section-2.3.1 RFC 3279 section 2.3.1].
[https://crt.sh/?id=197347381&opt=cablint,x509lint This certificate] and [https://crt.sh/?iCAID=750&minNotBefore=2000-01-01&n=1000&cablint=734 21 others] all have a Key Usage of, among other things, "Key Agreement", which is inappropriate for an RSA public key. Many of these were revoked soon after they were issued. If the first ones were a problem, why was the problem not fixed? cablint marks this as an error, as it's a violation of [https://tools.ietf.org/html/rfc3279#section-2.3.1 RFC 3279 section 2.3.1].
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "The template for this certificate was fixed and based on internals test and validation, we contacting the client, we asking for a new CSR and proceed to revoke and reissue the certificate, supporting into the installation process."


==Issue V: Failure to Respond Quickly To Problem Reports (August 2017)==
==Issue V: Failure to Respond Quickly To Problem Reports (August 2017)==
Line 117: Line 194:


Jonathan did not receive any direct response from PROCERT to his reports. While the BRs currently contain no requirement to respond to the problem reporter within any time period, they do contain a requirement to revoke misissued certificates within 24 hours. This clearly did not happen in any of the cases above. Mozilla allows some unofficial leeway in this based on an assessment of the security risk, if there is careful published analysis and a timeline is given for revocation. That has not happened in this case.
Jonathan did not receive any direct response from PROCERT to his reports. While the BRs currently contain no requirement to respond to the problem reporter within any time period, they do contain a requirement to revoke misissued certificates within 24 hours. This clearly did not happen in any of the cases above. Mozilla allows some unofficial leeway in this based on an assessment of the security risk, if there is careful published analysis and a timeline is given for revocation. That has not happened in this case.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "We tested our certificates in our test environment, we analyze the issues and apply measure to solve the issues, later, the team takes actions, modify certificates templates, work in the CA, made test, generated new certificates in our internal environment. Then contacted the clients and agree a revocation date, revoke all the certificates with problem and reissue the certificates with the standard complying, check the correct application of CA Browser Forum, implant a regular training program (including test (operational and theory) to our staff in order to prevent and solve any issue, finally proceed with a dismissal of one operator."


==Issue W: Test Certificates Issued in Publicly Trusted Hierarchies (August 2017)==
==Issue W: Test Certificates Issued in Publicly Trusted Hierarchies (August 2017)==


[https://crt.sh/?id=197073488&opt=cablint This certificate] and [https://crt.sh/?id=197155020&opt=cablint this certificate] have "test" values in the CN, OU and stateOrProvinceName. They have the emailProtection EKU but no email address in the CN or SANs.
[https://crt.sh/?id=197073488&opt=cablint This certificate] and [https://crt.sh/?id=197155020&opt=cablint this certificate] have "test" values in the CN, OU and stateOrProvinceName. They have the emailProtection EKU but no email address in the CN or SANs.
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "The certificate was revoked and we put enforce our security policy in order to prevent futures events. Also we instruct our operational staff regarding internal process and IT Security topics".


==Issue X: High Percentage of Revocations (August 2017)==
==Issue X: High Percentage of Revocations (August 2017)==
Line 140: Line 225:


While this is not against any policy, it does seem strange. Is there something wrong with these certificates? If so, what, and why has the problem not been fixed?
While this is not against any policy, it does seem strange. Is there something wrong with these certificates? If so, what, and why has the problem not been fixed?
=== PROCERT Response===
PROCERT [https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/nrXoE9JiAQAJ said]: "Staff takes actions considering the observations includes into the Mozilla bug. In order to that, we made an internal audit, check the issuance process, detected al the unconformities, contacting the clients, agree with the clients a windows to revoke and installing the new certificates. In order to duly comply, we proceeded to revoke certificates with observations (Mozilla Bug). We planning replace all the certificates with observations. That why you can appreciate a high percent into the certificates revocations".
===Further Comments===
The issue being raised here is not the large number of certificates that PROCERT is revoking (we might expect a large number of revocations, given all of the problems), but the fact that a large number are revoked very shortly after they are issued. Why does that keep happening? If they are being issued incorrectly, why are corrective steps not being taken?


<hr>
<hr>


Particular thanks to Jonathan Rudenberg for his research on many of these issues.
Particular thanks to Jonathan Rudenberg for his research on many of these issues.
Gerv
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1180623"

Navigation menu