Windows 7 chrome let’s encrypt problems

Is it okay?

1633164441970.png
 
Upgrading letsencrypt v2.0.23 package via the custombuild can allow some moderately old systems to connect to DA which currently fails to do so. New systems works fine with or without this upgrade. For extremely old systems there is nothing that can be done (except upgrading them).
I updated Letsencrypt as instructed.
The website now don't open until "CA certificate" is excluded in SSL setting
Previously it was only showing date error and now it dont even load.
 
You see there only the ISRG Root X1 in chain so when clients don't support this YUP then problems

Don't know am not sure it is a good idea to have the (trusted) chain x3 that is with the LE workarround removed while some maybe do need that and support it that way.

If it is totally not there then clients without support for the newer roots doesn't work i guess so i mean this ,so yes no good i don't know
x3t.jpg


So curious which solution is overall the better one while.

Upgrading letsencrypt v2.0.23 package via the custombuild can allow some moderately old systems to connect to DA which currently fails to do so. New systems works fine with or without this upgrade. For extremely old systems there is nothing that can be done (except upgrading them).
 
Last edited:
Didn't use or read full but please for those who has problems with windows maybe read here also sorry is it is deadend but there is older info and tool that supposed to work with same kind of problems in windows, to check


MANUALLY ...
 
Last edited:
FOR those clients and APPS having problems.

Pleas do look for solutions to have them updated somehow to use the right root certs.

While those are ofcourse not only having problems with connecting to your Sites / Apps , so the real best way to go is have them updating their stuff.
 
CENTOS boxes should probably also read here go to post 9 there!

and
 
I updated letsencrypt to `v2.0.23` according to the provided instructions. The `DST Root CA X3` indeed is removed now.

However, the letsencrypt upgrade broke SSL on port 993.

When I run `openssl s_client -connect mail.domain.com:993` I get:


Code:
---
no peer certificate available
---
No client certificate CA names sent
---

This works correctly `openssl s_client -connect mail.domain.com:443`
Code:
---
Certificate chain
 0 s:/CN=mail.domain.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---

I upgrade from letsencrypt v1.1.42. What could be the problem?
 
When I run `openssl s_client -connect mail.domain.com:993` I get:



I upgrade from letsencrypt v1.1.42. What could be the problem?
Did you do that test also for that update?

While on port 993 dovecot and co that mail. is handled by DA scripts and the settings of config .conf..... ( diferent way then such a test... i m not sure)

So check for example also the pure hostname itself ( so no mail. and no domainame but hostname) cert on that port in the test. ;) You have to renew LE certs before doing tests after the patch / update
 
Did you do that test also for that update?

While on port 993 dovecot and co that mail. is handled by DA scripts and the settings of config .conf..... ( diferent way then such a test... i m not sure)

So check for example also the pure hostname itself ( so no mail. and no domainame but hostname) cert on that port in the test. ;) You have to renew LE certs before doing tests after the patch / update
Thanks for your reply!

Did you do that test also for that update?

Yes, before the update, SSL IMAP was working (via exim). Exim itself still works, as connecting without SSL still works

So check for example also the pure hostname itself ( so no mail. and no domainame but hostname) cert on that port in the test. ;) You have to renew LE certs before doing tests after the patch / update

I just tried this as well (without the mail subdomain, on that domain, and also on the hostname). All have the same response on port 993
`openssl s_client -connect server.hostname.com:993`:
Code:
---
no peer certificate available
---
No client certificate CA names sent
---

I tried renewing the certificate via this method: https://help.directadmin.com/item.php?id=2087 But the issue is still there
 
Could you try this?
Code:
cd /usr/local/directadmin/custombuild
./build update
./build exim
./build exim_conf
./build dovecot
./build dovecot_conf
./rewrite_confs

It sometimes helps. After that, also check if the domain name domain.com (not hostname and not mail.domain.com) is present in the
/etc/dovecot/conf/sni directory

If that does not help, then I don't know.
 
If that does not help, then I don't know.

YUP then @DirectAdmin Support DA SUPPORT TICKETS IMPORTANT i THINK to solve this for most of the DA Users and BOXES in simple DOCS and patches

@DirectAdmin Support please make clear separations for parts upfront and then not in one BIG (LE...) SCRYPT anymore.

So kind of trees with total different scripts for different situations is much better to handle with problems, bugs and support and updates.

So which OS, Versions, OPenssl check, Lego, cloudflare, external dns, wildcard... , mailssl on domain , and such settings, as also yes no have to support older clients / apps , then not one script with so many logic... but the script only for that purpose and configs.

So more object / custom based.... ;)
 
Last edited:
cd /usr/local/directadmin/custombuild ./build update ./build exim ./build exim_conf ./build dovecot ./build dovecot_conf ./rewrite_confs
It takes a bit longer unfortunately. This upgraded exim from 4.92 to 4.94.2. Apparently something went wrong, incoming mails are not working anymore.

The exim logs show me R=virtual_user T=dovecot_lmtp_udp defer (-1): Failed to connect to socket /var/run/dovecot/lmtp for dovecot_lmtp_udp transport: No such file or directory. I tried to run ./build dovecot but this give me the error
Code:
*** There was an error while trying to configure dovecot. Please check configure/dovecot/configure.dovecot file.
The file configure.dovecot contains
Code:
#!/bin/sh

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var  --without-ic

Help is much appreciated! (I am starting to get quite nervous)

-EDIT
Probably more relevant, I also see: Unable to open /etc/scl/prefixes/devtoolset-7!
 
Last edited:
@aln123 please open new topic

With more info's

OS and versions used also versions DA and yes no custombuild and version

Hope you have backups!
Before doing updates

You have DA license with support ?
If so open ticket there

Yes here in this topic is about the Letsencrypt SSL problems after 30 september 2021

But if more have to be updated as your exim was on older version, maybe that was because OS or some is not supported, therefore DA support has to know more then only the errors.

Log files and versions and some info about configs i think are needed.

If you have or had some custom openssl or changes not default before for httpd or php and so on?


UH do you have centos6!?!?
2724 - Use devtoolset-7 to build dovecot on CentOS6.
 
Last edited:
Hi again everyone. It seems the discussion got slightly derailed bu unrelated issues. Lets get back to the main topic.

There is one last resort to make sure old systems can access DA panel and websites. That is to dropping LetsEncrypt completely in favor of a different certificate provider, for example ZeroSSL.

We have prepared an early tech preview of a ZeroSSL support. For this to work we released a new lego version (capable of issuing ZeroSSL certificates) and new letsencrypt version v2.0.24. Participation in this early preview is controlled by the existence of /root/.zerossl file. If this file is present DA will try issuing cert from ZeroSSL, if this file is absent everything will work as before (certs issued from LetsEncrypt).

If you would like to try it out please do the following:

Code:
# /usr/local/directadmin/custombuild/build update
# /usr/local/directadmin/custombuild/build lego
# /usr/local/directadmin/custombuild/build letsencrypt
# touch /root/.zerossl
# /usr/local/directadmin/scripts/letsencrypt.sh request server.name.example.net

The steps are actually doing:
  • Downloading latest package versions via custombuild
  • Installing latest lego package (should be version 953d5c85145b6a2b9a52f2d919faf23e04a359b3)
  • Installing latest letsencrypt package (should be version v2.0.24)
  • Enabling participation in early ZeroSSL certs support experiment
  • Renewing main server certificate
If everything works as expected testing server certificate with openssl should show ZeroSSL certificate:

Code:
# openssl s_client -connect example.net:2222 -servername example.net
...
---
Certificate chain
 0 s:/CN=example.net
   i:/C=AT/O=ZeroSSL/CN=ZeroSSL ECC Domain Secure Site CA
 1 s:/C=AT/O=ZeroSSL/CN=ZeroSSL ECC Domain Secure Site CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust ECC Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust ECC Certification Authority
   i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
---
...

Please note that you might need to use different command for main cert renewal if you want certificate to include multiple aliases as was pointed out by @Richard G earlier.

If /root/.zerossl file is present all certs issued will use ZeroSSL provider (existing LetsEncrypt certificates will be replaced by ZeroSSL certificates on renewal).

This solution is intended for those who really need to maintain websites for old clients. Please report if you tried it out and it helped. We expect this experimental ZeroSSL mode to be dropped or replaced by proper ZeroSSL switch in GUI in the future depending on how this experiment goes.
 
Last edited:
Back
Top