I wanted to also add that I'd like Entrust to address why they don't stop certificate issuances when they find out they're misissuing certificates?
As part of my series on Entrust <https://webpki.substack.com/t/entrust-considered-harmful>. In Part 2 <https://webpki.substack.com/p/entrust-considered-harmful-part-2> I found a concerning issue from Entrust that went unnoticed at the time, which shows a pattern of gross-negligence when it comes to incident response: Entrust: SHA-256 hash algorithm used with ECC P-384 key <https://bugzilla.mozilla.org/show_bug.cgi?id=1648472> In this incident, Entrust discovers that they're misissuing certificates on 2020-06-17. Despite finding out about this incident, they continue to misissue certificates all the way till 2020-06-24: https://crt.sh/?id=2998515551&opt=zlint There have been a couple of examples of Entrust making this decision in the past, such as: Entrust: Printable String Constraint Failure <https://bugzilla.mozilla.org/show_bug.cgi?id=1635096>. Similar to the previous incident, they did not disable issuance on their systems that was capable of misissuing certificates (emphasis mine): > Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. The CA software has a bug which encodes quotation marks in the organization field using PrintableString instead of UTF8String. *This software has not been fixed at this time.* And more recently, we saw this behavior in the start of this saga: Entrust: EV TLS Certificate cPSuri missing <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4> On Saturday, May 11, 2024 at 6:37:52 PM UTC-4 Wayne wrote: > I can't speak for everyone but in an issue of public trust asking for > private feedback and concerns is not helping matters. > > One of the prevalent topics that have came up in these issues is shorter > certificate lifespans, certificate automation and how Entrust are working > very hard with their customers. I'm very curious if Entrust can quantify > this in any way? > > Taking a step back and just looking at their public statements regarding > lifespans, automation and ACME should give us an idea of their internal > viewpoint and how this topic is presented to customers. Outside of the > first issue I won't be quoting bugzilla, it's there solely to provide > context as I can't see an earlier point that automation was promised. > > Let's dive in, sources all provided if there are any questions about the > rough transcript or context. > > *1: 2023-03-27: Entrust: Delayed Revocation for EV TLS Certificate > incorrect jurisdiction* > https://bugzilla.mozilla.org/show_bug.cgi?id=1804753#c8 > *---* > Late revocations are base primarily by Subscribers which have not > implemented automation. We have increased our efforts to extend > implementation of ACME. We are also considering implementing the ACME > Renewal Information (ARI) Extension, which allow the certificate to be > automatically renewed before the revocation date. > > In the shorter term, we will provide Subscribers with automated reminders > on the revocation date for miss-issued certificates. We will plan to allow > short extensions, based on the severity of the miss-issuance. > *---* > > > > *2: 2023-04-21: Google’s 90 day proposal for TLS certificates* > > https://www.entrust.com/blog/2023/04/googles-90-day-proposal-for-tls-certificates/ > *---* > Even if CAs and other browsers don’t share Google’s objectives, there is a > chance that Google could unilaterally make this change in its root program > and force the entire industry in this direction in a time of their > choosing. We hope that browsers will not make this decision unilaterally, > but instead allow the decision to be made with broad industry and website > owner consensus. > > Another issue is that Google has presented no public research or factual > data showing that such a change to the ecosystem is necessary or useful in > many use cases. We believe there will be much discussion before a 90-day > ballot will pass at the CABF as several CAs have indicated that a > requirement for 90-day certificates might have far-reaching implications. > There have also been several EU governmental bodies concerned over the > market and competitive implications of Google’s proposal and the impact on > eIDAS Qualified Website Authentication Certificate objectives, which are > now being reasserted in the EU’s update of its eIDAS legislation. > > Entrust does not believe that a maximum 90-day limit for TLS certificate > lifetimes is the only method to drive automation and the deployment of > ACME. Additionally, Entrust doesn’t believe that ACME is the only method > for automation, or that it would be accepted by some of the most complex > subscriber secure server deployments. Rather, we believe subscribers should > be encouraged to deploy automation, but do not need to be discouraged by > the cost and complexity of certificates with 90-day maximum validity. > > While Entrust is not currently in favor of a mandatory 90-day certificate > limit, we have no objection to 90-day certificates if that is what a > website wants to use. We are always working to improve or extend its > validation, issuance, and management processes, including greater use of > automation through integrations with certificate lifecycle management (CLM) > solutions such as Entrust Certificate Hub, AppViewX, Venafi, and > ServiceNow, as well as automation through ACME v2, CMP, SCEP, and other new > methods. > > We understand that this Google proposal may be causing our customers > considerable concern. In accordance with Google’s instructions on its > Chrome Root Program Policy, we encourage customers to direct any questions > or input regarding the Google proposal to [email protected]; please > feel free to share a copy with us at [email protected]. > *---* > > > > *3: 2023-07-26: Entrust Cybersecurity Institute Explains: 90-day TLS/SSL > Certificate Lifecycle* > https://www.youtube.com/watch?v=GcKunPD5SRw > *---* > 0:41-1:48 > Today we're using certificates that are generally valid for about a year. > Technically, according to the requirements, we can go to 398 days to give > you a bit of room so that you can have one day of the year at which you > renew your certificates. That is something that is easy to remember, > scheduling your agenda as a yearly renewal of those certificates when they > need to happen. > > When they're moving to shorter-lived certificates, such as the proposed 90 > days, this means that you need to do this now four times a year in a window > of 90 days. > > Moving to 90-day certificates means that you're practically going to renew > your certificates probably every 60 days. Meaning that in the end, you have > to replace your certificates four to six times a year, depending on what > window you allow to renew that certificate. > > 90-day certificates will have a few benefits. So one is that they will > drive automation. > > > 2:51-3:30 > That doesn't [mean to] say that there's no problems and that 90-day > certificates are actually going to solve this. Crypto agility is important, > but that means more than just automating your certificate lifecycle. > > For example, if the CA would give you an indication through the automated > system that your certificate must be replaced, how does currently the CA > know that your system is capable of running a certain algorithm? Have you > updated your libraries? > > So we still have a long step ahead of us really to make that crypto > agility a reality. > > 4:41-end > > We're working with the Internet Engineering Task Force, where Anthos(?) > created a proposal for a sort of auto-discovery based on the most used > automation, the ACME Auto Certificate Management Environment. > > And that would help our customers actually to simplify this mechanism of > renewing certificates in different platforms with different systems, > without having to reconfigure every individual system to work with the > certificate authority and the type of certificates they're dealing with. > Together with[sic] very important is one of the risks of automation, is > that you're not doing it as a human. > > If you do a process, if you follow a step-by-step process that is defined > and tested, then you know the outcome, because you're following the steps. > But in automation, something might go wrong. And how do you know? You need > to make sure that systems are notifying you as someone is watching the > notifications. > > That's also why in this similar proposal, we've included the mechanism of > backup configuration. So if one process would fail, there is another > process that can be followed. But other things are still in development. > And we will see how that turns out. But the ecosystem seems to be > supporting it. > *---* > > > > *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust and > TLS/SSL Certificate Management* > https://www.youtube.com/watch?v=nd0QCvu2F_E > *---* > 1:20-2:18 > > Well, first I would say we need to adopt automation. But then at the same > point, I would point them at the risk of automation. Where processes by > humans are easily manageable and can have multiple steps to ensure they > flow correctly. Without automation, this could be more challenging. > > For example, if you implement automation for your TLS certificates, this > means that you need to have a credential for your certificate authority. > You need to also have a credential, for example, for your domain name > provider, your DNS system. And that's all needed to prove domain control > and to make sure that a certificate with the right identity is issued for > your endpoints. > > But what if these credentials get compromised? Look at the DNS system. > *---* > > > > *5: 2023-08-14: Short-lived Certificates finally approved* > > https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/ > *---* > After more than 10 years, short-lived TLS certificates are finally > permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv > Markham started a short-lived certs discussion in 2014, where he advised he > was reviewing the 2012 CA/Browser Forum discussion on the topic. He advised > that short-lived certificates was a plank of the Mozilla revocation > strategy. There was also a paper prepared in 2012 called Towards > Short-Lived Certificates. The paper stated OCSP is as good as dead, so the > CAs should issue certificates with a very short lifetime. I suppose no one > thought it would take so much time. > > Short-lived certificates are designed to help address a certificate > revocation issue. Back in 2012, Adam Langley discussed the seat-belt issue, > where it works fine, but snaps when you crash. This was based on the fact > the browser implements soft-fail revocation checks where the CRL or OCSP > response is ignored. > *---* > > > > *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges Facing > Organizations* > > https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/ > *---* > Certificate lifespan is getting shorter > > Over the years the cybersecurity industry has undergone notable > transformations requiring organizations to implement new best-practice > standards, often at a short notice. > > In 2020, Apple unilaterally opted for shorter TLS certificate durations, > reducing them from three years to 398 days, thereby increasing the burden > on certificate management. Subsequently, Apple introduced shorter lifespans > for S/MIME certificates at the start of 2022. In the past year, both code > signing and S/MIME users faced additional alterations, while Google > proposed transitioning to 90-day certificates, a subject we have explored > in our latest webinar. Anticipating further changes, particularly with the > rise of artificial intelligence (AI) and the looming risk of post-quantum > (PQ) computing, organizations must enhance their agility. > > Today, TLS/SSL certificates are typically valid for about a year, > according to the Certification Authority Browser (CA/B) Forum requirements. > This yearly renewal cycle is convenient for organizations to manage and > schedule. However, transitioning to shorter-lived certificates, like the > proposed 90-day validity period, will require more frequent renewal > efforts. With 90-day validity, organizations will need to renew > certificates four times every 12 months within that timeframe. In practice, > due to the need for buffer time, certificates may need to be renewed every > 60 days. Ultimately, this change could lead to replacing certificates more > than six times every 12 months, depending on the renewal window chosen. > *---* > > Apologies that some of those got long, I wanted to preserve as much > context as possible given how little material we have to work with. > > I sincerely ask anyone if they can find any further communication on these > topics by Entrust. Their helpdesk has tutorials on specific software > setups, but I'm not seeing any actual push for their subscribers to do > anything. > > It would be very beneficial for Entrust to provide us with any information > on what they've been communicating to their customers to promote shorter > certificate lifespans and automation. > > - Wayne > > On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote: > >> To Ben Wilson and the Mozilla Community: >> >> >> >> I want to acknowledge your letter and the input from you and the >> community. We agree that we have go-forward opportunities to improve. >> >> >> >> To that end, I want to confirm our intent to provide a full written >> response to you and the community prior to June 7. Until then, please >> contact me directly with additional questions or feedback. >> >> >> >> Sincerely, >> >> Chris Bailey >> >> VP-Digital Certificates >> >> Entrust >> >> >> >> *From: *'Ben Wilson' via [email protected] < >> [email protected]> >> *Date: *Tuesday, May 7, 2024 at 10:59 AM >> *To: *[email protected] <[email protected]> >> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents >> >> Dear Mozilla Community, Over the past couple of months, a substantial >> number of compliance incidents have arisen in relation to Entrust. We have >> summarized these recent incidents in a dedicated wiki page: https: >> //wiki. mozilla. org/CA/Entrust_Issues. >> >> Dear Mozilla Community, >> >> Over the past couple of months, a substantial number of compliance >> incidents have arisen in relation to Entrust. We have summarized these >> recent incidents in a dedicated wiki page: >> https://wiki.mozilla.org/CA/Entrust_Issues >> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>. >> >> In brief, these incidents arose out of certificate mis-issuance due to a >> misunderstanding of the EV Guidelines, followed by numerous mistakes in >> incident handling (including a deliberate decision to continue >> mis-issuance), which have been compounded by a failure to remediate the >> issues in a timely fashion in line with well-established norms and root >> store requirements. >> >> Our preliminary assessment of these incidents is that while they were >> relatively minor initially, the poor incident response has substantially >> aggravated them and the progress towards full remediation remains >> unacceptably slow. This is particularly disappointing in light of previous >> incidents in 2020 (#1651481 >> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$> >> >> and #1648472 >> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>), >> >> which arose out of similar misunderstandings of the requirements, similar >> poor decision-making in the initial response, and lengthy remediation >> periods that fell well below expectations. Entrust gave commitments >> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> >> >> in those bugs to address the root problems through process improvements, >> and it is concerning to see so little improvement 4 years later. >> >> In light of these recent incidents, we are requesting that Entrust >> produce a detailed report of them. This report should cover in detail: >> >> - The factors and root causes that lead to the initial incidents, >> highlighting commonalities among the incidents and any systemic failures; >> - Entrust’s initial incident handling and decision-making in response >> to these incidents, including any internal policies or protocols used by >> Entrust to guide their response and an evaluation of whether their >> decisions and overall response complied with Entrust’s policies, their >> practice statement, and the requirements of the Mozilla Root Program; >> - A detailed timeline of the remediation process and an apportionment >> of delays to root causes; and >> - An evaluation of how these recent issues compare to the historical >> issues referenced above and Entrust’s compliance with its previously >> stated >> commitments. >> >> Finally, Entrust’s report should include a detailed proposal on how it >> plans to address the root causes of these issues. In light of previous >> guarantees >> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> >> >> given by Entrust in 2020 to ensure speedy remediation in future incidents, >> this proposal should include: >> >> - Clear and concrete steps that Entrust proposes to take to address >> the root causes of these incidents and delayed remediation; >> - Measurable and objective criteria for Mozilla and the community to >> evaluate Entrust’s progress in deploying these solutions; and >> - A timeline for which Entrust will commit to meeting these criteria. >> >> We strongly recommend that Entrust go beyond their existing commitment >> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1886532*c0__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8gYsLCM$> >> >> to offer systematic, automated solutions for effective remediation, like >> ACME ARI and that it also include clear and measurable targets for the >> adoption of these tools by new and existing subscribers. >> >> This report should be submitted to Mozilla dev-security-policy mailing >> list for evaluation by the community and Mozilla, who will weigh whether >> Entrust’s report presents a credible and effective path towards >> re-establishing trust in Entrust’s operation. Submission should be no later >> than June 7, 2024. >> >> We thank community members for their engagement on these issues and look >> forward to their feedback on Entrust’s report and proposed commitments. >> >> Thanks, >> >> Ben Wilson >> >> Mozilla Root Program >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com >> >> <https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm*2BRG0YHCA*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM525_4vY$> >> . >> *Any email and files/attachments transmitted with it are intended solely >> for the use of the individual or entity to whom they are addressed. If this >> message has been sent to you in error, you must not copy, distribute or >> disclose of the information it contains. Please notify Entrust immediately >> and delete the message from your system.* >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9400cb80-7eaa-4cc7-a077-341469e6e302n%40mozilla.org.
