Are they out of business since their Sectigo cert has been expired since Dec 5?

The cert is for * Also, their support hasn't replied.

👍︎ 4
📰︎ r/dreamhost
👤︎ u/4ccount4n7
📅︎ Dec 08 2020
🚨︎ report
Reminder: Sectigo root expires Saturday morning

In case you get calls for old, mostly obsolete stuff (or what some of us call production critical) that suddenly stops working...the root used by Comodo/Sectigo for the last 20 years expires Saturday 30 May 2020 at 7am Eastern.

Primary impact will be systems older than:


macOS Sierra 10.12.1 Public Beta 2

iOS 10


Windows XP (via Automatic Root Update; note that ECC wasn't supported by Windows until Vista)

Windows Phone 7


Firefox 3.0.4 (COMODO ECC Certification Authority)

Firefox 36 (the other 3 roots)


Android 2.3 (COMODO ECC Certification Authority)

Android 5.1 (the other 3 roots)


Java JRE 8u51
👍︎ 110
📰︎ r/sysadmin
👤︎ u/Dal90
📅︎ May 28 2020
🚨︎ report
Sectigo root CA expiring, may not be handled well by slightly older linux versions

It looks like some older distributions of linux (we've seen issues with Deb 9 and earlier and Ubuntu 16.04 and earlier) will not properly expire/ignore this root cert unless it is actually removed. Ubuntu 18 and up, as well as Deb 10 are unaffected. To verify this, create a host based on one of these distributions and roll the time forward Jun 1st or so. Running curl against certain domains will fail with a certificate expired error. For example: curl

This happens even if ca-certificates has been updated. This obviously does not affect all domains, but we have a number of critical internal and external endpoints that use comodo/sectigo certs that had the issue.

EDIT: As someone else has pointed out, this is almost certainly an openssl 1.0.2 bug. Unfortunately system upgrades don't help the situation (unless you upgrade the actual distribution). We have noticed that programs that don't depend on openssl (for example, compiled go programs, python) won't exhibit the problem. Ruby, on the other hand, will have the same issues as curl.

EDIT: I'll go ahead and post the fixes for debian-based systems. Note that reissuing your own certs can fix the issues with those certs, as your provider should no longer include the expired root in the chain. But for domains you don't control, you will still need to be sure you have the later intermediate certs and have removed the expired cert. For Deb 9/Ubuntu 16:

  • Edit /etc/ca-certificates.conf -- remove AddTrust_External_Root.crt. You can automate this with sed, if need be.
  • apt update && apt install ca-certificates # Be sure you have the latest bundle
  • For good measure update-ca-certificates -f -v.

That should remove all the links to AddTrust_ExternalRoot in /etc/ssl/certs. Test with curl against an affected domain

For older distributions (deb 8, ubuntu 14), you may want to do a full systems upgrade first, THEN actually rm /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt. You should at least be sure you have the latest openssl you can get and that you have the latest ca-certificates installed.

FINAL EDIT: Our only lingering issue, which is easy to work around is that git has issues with the reissued cert for our private repo. On those host

... keep reading on reddit ➡

👍︎ 60
📰︎ r/linux
👤︎ u/hayzeus
📅︎ May 28 2020
🚨︎ report
About the Sectigo certificate: howcome browsers are fine?

TL;DR: a Web Server always sends the same certificate chain, right? Why does the FortiGate see the expired cert in the chain, but browsers don't and serve the cert thats due in 2038?

Okay so this is more a TLS/certificate-based question than a FortiOS-related question, but the Certigo certificate-thing got me wondering: why is it that when I visit a website in a browser that has a certificate signed by the affected Root CA, my browser doesn't show any errors (and is actually showing a different Root CA that is unaffected), but then the FortiGate shows the certificate chain to be untrusted (due to the expired certificate)?

So first things first, I am well aware that FortiOS and browsers/Windows don't share the same Root CA Store. I am also well aware that it is expected for the FortiGate to "man in the middle" with the configured CA certificate in the SSL/SSH profile to intervene in the connection as the certificate is untrusted.

What strikes me though is that the delivered chain seems to be different when SSL/SSH Inspection is applied, where the 'wrong' chain is sent when SSL/SSH Inspection is applied, but the 'Correct' chain is sent when no SSL/SSH inspection is performed (or when you don't notice it because you set the profile to allow untrusted certs)? If the same chain would be sent regardless of inspection (which I'd expect), then your browser should also show a warning page that the certificate is incorrect?

So the real question to me is: are websites actually sending different chains? I find that hard to believe, how does the browser know the right chain when no inspection is applied? I read somewhere that it might be due to browsers preffering a SHA2-based certificate when available? Or something regarding cross-signing (which I don't fully understand yet)?

👍︎ 15
📰︎ r/fortinet
👤︎ u/rowankaag
📅︎ Jun 02 2020
🚨︎ report
Sectigo seems to have screwed up ClickOnce signing

If you sign and timestamp a ClickOnce manifest in Visual Studio with a Sectigo/Comodo code signing certificate, the countersignature is no longer valid as Sectigo's "AddTrust" Root certificate has expired.

It would have been nice to get some sort of warning from them or their reseller. It took me hours to figure out that this was the reason that Windows SmartScreen was acting up.

Workaround: Disable timestamping.

Edit: Visual Studio didn't show any error message or warning and pretended that everything had been published just fine.

👍︎ 7
📰︎ r/dotnet
👤︎ u/hypermegaglobal
📅︎ Jun 01 2020
🚨︎ report
The issues we saw with the expiring Sectigo certificate on May 30th have only just started.

A colleague shared this article with me today regarding the fallout of the Sectigo certificate that expired on May 30th and why we can expect more frequent and more severe issues in the coming years thanks to the original root CA certificates hitting their EOL and expiring. It's very informative and a must read if you're responsible for certificates in your organization.

👍︎ 31
📰︎ r/sysadmin
👤︎ u/chafe
📅︎ Jun 16 2020
🚨︎ report
Jabber MRA Sectigo certificate issues - 30th of May 2020

Hi guys,

We were just hit by an issue with the Trusted CA certificates (not the signed server certs.) issued by Sectigo (formerly COMODO) expired on the 30th of May and caused outages to one of our MRA deployments.

Seems like it's a known fault and Cisco already have a tech. bulletin on how to fix:

Hope this helps anybody else running into this one.

👍︎ 10
📰︎ r/ciscoUC
👤︎ u/TudorAdrian
📅︎ Jun 03 2020
🚨︎ report
Sectigo SSL Error

Looks like Sectigo has a misconfiguration on their SSL settings. The SSL certificate they use for their website matches * and not so it is showing a domain-mismatch error when going to their website.

👍︎ 2
📰︎ r/msp
👤︎ u/guiltykeyboard
📅︎ Apr 17 2020
🚨︎ report
Sectigo AddTrust External RootCA Help Needed

Hello r/sysadmin, I am in need of some assistance with regards to the SSL certification path. I am getting SSL errors as a result of the Sectigo AddTrust External RootCA. My webserver in question is hosted in IIS10 on premise at my facility, so I can't ask my host to do it for me. I know I need to update the certificate on the server to include the new CA bundle. My domain registrar has provided the following instructions [here] ( Where I followed the instructions here from Option 1:

  • Go to the "Domain List" section. Make sure you have the filter set to "All products".

  • Locate the affected SSL under the corresponding domain name.

  • Click "Manage" next to the certificate.

  • Click "Download" next to the affected certificate to get the SSL with updated CA-bundle that contains the new updated root

  • Install the downloaded SSL with the updated CA-bundle on your server. Based on server type and its configuration, you’ll need to update the CA-bundle only or re-install the SSL from scratch. Please contact your hosting support, if you need assistance.

Next I followed the instructions in the article here. However when I go to my website and load the page I am still getting SSL errors. I am not sure what to do anymore and don't want to make any mistakes that totally invalidates my certificate somehow. Any help and guidance you can provide will be more than appreciated.

👍︎ 2
📰︎ r/sysadmin
👤︎ u/xXXTGPxXX
📅︎ Jun 04 2020
🚨︎ report
Cannot solve the Sectigo expired certificate issue

So an old CA certificate of Sectigo expired on the 30th of May and it's causing colleagues of mine not to be able to access certain websites properly. One example being:

They are Windows 10 PC's with automatic updates enabled.

I removed the expired AddTrust CA certificate and installed the new USERTrust ones and also the COMODO ones as the user and as an admin and restarted the PC even. Tried different browsers, but it's not working.

This isn't my responsibility and it's wasting my time that I need to work on my own priorities, so it's a bother.

Does anyone know what could still be the issue? It works fine from my Linux computer.

I have a feeling it's a GPO thing, but I'm not sure if and where to look

👍︎ 2
📰︎ r/sysadmin
👤︎ u/Turboslak
📅︎ Jun 04 2020
🚨︎ report
Comodo SSL, Sectigo SSL or is it Instant SSL? Seems like an identity crisis

I just got an email from Comodo telling me I need to renew my SSL. So I logged in and then got redirected to Sectigo. This confused me so I picked up the phone and call the support number. They then redirected me to the InstantSSL website where I needed to purchase a new SSL. But I bought my SSL through Comodo.

Why 3 companies? This seems ridiculous and doesn't instill trust one bit.

Can I get a recommendation for a good SSL provider that isn't going to be so convoluted?

👍︎ 9
📰︎ r/webdev
👤︎ u/lamordnt
📅︎ Dec 05 2019
🚨︎ report
Free SSL test checks for issues similar to recent Sectigo root CA expiration
👍︎ 2
📰︎ r/cybersecurity
👤︎ u/KeyDutch
📅︎ Jun 04 2020
🚨︎ report
Anyone using OCSP checking with GoDaddy or Sectigo?

Been trying to use OCSP stapling with GoDaddy but get either "Timed Out" or "Request unauthorized" at the bottom of the certificate status page when I enable it. I've done some packet captures and can definitely see the F5 connecting outbound to but not sure how to troubleshoot beyond that.

I'm primarily looking to catch certs that may be revoked or re-issued, since the F5 already catches those that have expired. Most of our certs are issues by GoDaddy but there's some Sectigo ones as well.

BigIP version is; both the external and mgmt interfaces do have outbound internet.

👍︎ 3
📰︎ r/f5networks
👤︎ u/greenlakejohnny
📅︎ Apr 27 2020
🚨︎ report
Old Comodo / Sectigo Root CAs expiring on 5/30/2020

In case this leg work I've been doing for the past year helps anyone else:

An older set of Root CAs signing them are expiring 30 May 2020. This will primarily affect OSes, Firefox (using it's own CA Trust Store), and Java versions older than the 2015-2016 time frame. The exact versions best I can figure when the new CAs are included are on the chart...but disclaimer this is only my best effort research.

In a case like mine, apps using older versions of Java that connect to endpoints using the Sectigo certificates will need to have their CACerts file updated with the new roots before then. Which is going to be like herding cats only to have 16-3/4 developers panic the Friday before these Root CAs expire on Saturday, and on Monday morning after odds and ends fail 4 managers will be asking why management wasn't notified and I will have to forward them the emails and change records they were included on. I will also get asked why someone running OS X Snow Leopard using Firefox 10 on their personal machine wasn't able to connect to Citrix and how we can prevent this in the future because it caused three days of downtime for them until they were FedEx'd a USB drive with the new certs. This will be despite a kick-off meeting I'm planning for the end of this month to give folks 90 days to get their shit together (enough time to do the work, not enough to let it drop of radar screens).

Sorry it's not the best resolution as some of that was a copy-of-a-copy. If you're using Sectigo certs, you can scan your site at ... that's where I grabbed the screen captures of the Root & Intermediate CA Certs used in the above link.

Here are the sources I used to to figure out which release of what included the newer CAs:

No single source of truth for Java that I can find, Google the cert name along with Java Release Notes then cross-index with

👍︎ 10
📰︎ r/sysadmin
👤︎ u/Dal90
📅︎ Feb 12 2020
🚨︎ report can no longer working after Sectigo AddTrust External CA Root Expiration…
👍︎ 2
📰︎ r/plexguide
👤︎ u/admin9705
📅︎ May 31 2020
🚨︎ report
Windows 10 Bridge installer Sectigo certificate wierdness

The following script yielded a passing GPG signature check, but upon execution Windows warned of the install of an executable from an unknown publisher. I inspected the executable and verified the certificate was already properly trusted. I then retried the commands and no longer received publisher warnings on install.

set rev=2.0.27
set file=trezor-bridge-%rev%-win32-install.exe
set sig=%file%.asc
set repobranch=trezor/webwallet-data/raw/master
set uri=

curl -LO %uri%/%file%
curl -LO %uri%/%sig%
gpg2 --verify %sig% %file% && %file%

It only happened on the first attempt, and I have no rational for why the disk cache may have been flushed for the GPG command but not the install command.

Obviously just weirdness on my system, but I thought I'd post in case it ever shows up again for anyone else.

👍︎ 2
👤︎ u/brianddk
📅︎ Apr 24 2020
🚨︎ report
Sectigo's OCSP stapling issues earlier this week, who experienced issues as well?

After getting reports on April 23th around 18:00 (+0000) that multiple websites weren't responding to client requests I went my way to find a why. The websites wouldn't load in any of my browsers but they would when using curl. The Apache error log revealed the following errors:

[ssl:error] [pid 28983:tid 3731023406848] AH01941: stapling_renew_response: responder error
[ssl:error] [pid 23198:tid 3730998081280] AH01941: stapling_renew_response: responder error

When testing the OCSP responses with openssl all seemed well:

openssl ocsp -issuer chain.pem -cert cert.pem -url
WARNING: no nonce in response
Response verify OK
cert.pem: good
    This Update: Apr 22 11:48:29 2019 GMT
    Next Update: Apr 26 11:48:29 2019 GMT

Until we repeated a few requests quickly after one and another which resulted in an actual error:

openssl ocsp -issuer chain.pem -cert cert.pem -url
Error querying OCSP responder

Sectigo did report a service degradation between April 24th 13:53 and 23:25 (+0000) but based on my logsthe problems started on April 23th 15:50 until at least the following morning (April 24th, 07:30) at which point we disabled OCSP stapling at the last server running Apache (Nginx was unaffected).

So far I don't know what the actual cause for the outage has been but as there was a migration planned not long before the issues arose it would seem logical to assume this has played some sort of role in the issues experienced.

>Please be advised we will be migrating our OCSP Sectigo Certificate traffic on to a new service provider on Monday, April 22, 2019, at 12 PM EST

So far it's been pretty quiet around this issue and it's impact besides this post on the Apache mailing list.

So I wonder if any other sysadmin's out there experienced issues in the fields as well?

👍︎ 19
📰︎ r/sysadmin
👤︎ u/sPENKMAn
📅︎ Apr 25 2019
🚨︎ report
Comodo becomes "Sectigo" [SSL Certs]

If you see a new name in your SSL details, "Sectigo", it's the newest incarnation of the well known Comodo ssl provider.

👍︎ 3
📰︎ r/ladydevs
👤︎ u/curly_brackets
📅︎ Jan 15 2019
🚨︎ report
Sectigo EV Code Signing at The Cheapest Prices $263…
👍︎ 2
📰︎ r/u_codesigncert
👤︎ u/codesigncert
📅︎ Jan 23 2020
🚨︎ report

Please note that this site uses cookies to personalise content and adverts, to provide social media features, and to analyse web traffic. Click here for more information.