Closed zimico closed 3 years ago
Hello,
original root CA that cross-signed Let's Encrypt root expired yesterday. However, there is current and valid ISRG Root X1 that is present in the trusted cert store among OSes. Some software can wrongly mark the certificate invalid, even though it should trust ISRG Root X1. I noticed this issue in e.g. non-up-to-date gnuTLS lib or some Android versions).
Can you check your certificate chain, please? It should be like
your server name
\
\
Let's Encrypt R3 intermediate
\
\
ISRG Root X1 (valid and trusted)
\
\
DST Root (expired and should be ignored)
can you also check some other browser or device without Kaspersky installed?
Dear,
Thank for the info. I use ssl online checker and the cert is ok .
The cert chain is:
Common name: DST Root CA X3
Organization: Digital Signature Trust Co.
Issuer: DST Root CA X3
Validity period: 30/09/2000 - 30/09/2021
\
Common name: ISRG Root X1
Organization: Internet Security Research Group
Issuer: DST Root CA X3
Validity period: 20/01/2021 - 30/09/2024
\
Common name: R3
Organization: Let's Encrypt
Issuer: ISRG Root X1
Validity period: 04/09/2020 - 15/09/2025
\
Common name: mail.servername.vn
Issuer: R3
Validity period: 06/09/2021 - 05/12/2021
We are working with Kaspersky and waiting for their reply. Some very old windows 7 users also report this issue (no kaspersky antivirus installed).
Regards, Minh.
Some very old windows 7 users
That could be unsolvable problem. Let's Encrypt use its own CA root ISRG Root X1
which is not present in obsolete OSes and software (like old Android, Win XP, Java something?, etc...). I am not sure about Win 7, however.
You can try Firefox, which uses its own CA certificate stores and does not rely on the system one.
Dear, Just some updates. Another zimbra server today shows all services in red. When using zmcontrol status command, there is the following error: Unable to start TLS: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed when connecting to ldap master.
Letsencrypt has just renewed on 1st Oct 2021.
Thanks for update. I am working on an update to prefer ISRG Root X1 root cert.
I described the steps we took to adopt to the certificate changes:
https://community.letsencrypt.org/t/zimbra-renewal-problems-with-r3/160842/48?u=sphinx-nh
I described the steps we took to adopt to the certificate changes:
Thanks for tips. These steps are somewhat similar to what I prepared in chain
branch but I wasn't able to test it yet.
Thank for the news. I am waiting your official guideline to renew our cert. Hope it will be available soon.
That could be unsolvable problem. Let's Encrypt use its own CA root
ISRG Root X1
which is not present in obsolete OSes and software (like old Android, Win XP, Java something?, etc...).
This shouldn't be a problem. Let's Encrypt also offers the Cross-signed by DST Root CA X3
version of the certificate
Let’s Encrypt has a “root certificate” called ISRG Root X1. Modern browsers and devices trust the Let’s Encrypt certificate installed on your website because they include ISRG Root X1 in their list of root certificates. To make sure the certificates we issue are trusted on older devices, we also have a “cross-signature” from an older root certificate: DST Root CA X3. source
maybe add an extra parameter option to use the cross-signed version instead of the default
Cross-signed by DST Root CA X3
is the default now, but the DST Root CA X3
expired at Sep 30th. That is what this issue is about.
maybe add an extra parameter option to use the cross-signed version instead of the default
These changes are present in chain
branch now and I am working on a new testing environment to check if it works as expected.
I was finally able to finish my new testing server and tried the new version of letsencrypt-zimbra
.
@zimico please, checkout the chain
branch on your server, make sure you have certbot
version > 1.6 (there is a hint how to achieve that on Ubuntu bionic via pip3
) and force-renew the cert:
sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -fv
Dear, Thank a lot for the update. I successfully renew the cert on 1 server. I have trouble with another server with the same OS (Centos 7), Zimbra version (8.8.15). 2 servers use chronyd to sync time. The only difference is on the failed one, I did yum update certbot to update from version 1.9 to 1.11. The good server already is at cerbot 1.11. Output of the script:
obtain-and-deploy-letsencrypt-cert.sh: info: start nginx
obtain-and-deploy-letsencrypt-cert.sh: info: assemble cert files
obtain-and-deploy-letsencrypt-cert.sh: info: test and deploy certificates
obtain-and-deploy-letsencrypt-cert.sh: error: Verification of the issued certificate failed.
Run verification manually:
[zimbra@sm02 tmp.9VymZ2z260]$ zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key 0000_cert.pem chain.pem
** Verifying '0000_cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'
Certificate '0000_cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.
** Verifying '0000_cert.pem' against 'chain.pem'
ERROR: Unable to validate certificate chain: 0000_cert.pem: O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup:certificate has expired
Could you please give me your advice? My warmest regards
I've updated to version 0.6 of the zimbra-deploy script and get a certificate verification error in the test-environment.
root@chatter:/opt/letsencrypt-zimbra# sudo -Hiu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -vtt
obtain-and-deploy-letsencrypt-cert.sh: info: Certificate will expire in 30, certificate will be renewed.
obtain-and-deploy-letsencrypt-cert.sh: info: create csr config '/tmp/tmp.5kJXCfdCzS/openssl.cnf'
obtain-and-deploy-letsencrypt-cert.sh: info: generate csr '/tmp/tmp.5kJXCfdCzS/request.pem'
obtain-and-deploy-letsencrypt-cert.sh: info: stop nginx
obtain-and-deploy-letsencrypt-cert.sh: info: issue certificate; certbot_extra_args: --non-interactive --agree-tos --staging --staging
...
obtain-and-deploy-letsencrypt-cert.sh: info: start nginx
obtain-and-deploy-letsencrypt-cert.sh: info: assemble cert files
obtain-and-deploy-letsencrypt-cert.sh: info: test and deploy certificates
obtain-and-deploy-letsencrypt-cert.sh: error: Verification of the issued certificate failed.
root@chatter:/opt/letsencrypt-zimbra#
root@chatter:/opt/letsencrypt-zimbra# su - zimbra
zimbra@chatter:~$ cd /tmp/tmp.5kJXCfdCzS/
zimbra@chatter:/tmp/tmp.5kJXCfdCzS$ zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key 0000_cert.pem chain.pem
** Verifying '0000_cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'
Certificate '0000_cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.
** Verifying '0000_cert.pem' against 'chain.pem'
ERROR: Unable to validate certificate chain: 0000_cert.pem: C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
error 2 at 2 depth lookup:unable to get issuer certificate
When trying to renew the actual certificate the certbot exists with another error:
obtain-and-deploy-letsencrypt-cert.sh: info: issue certificate; certbot_extra_args: --non-interactive --agree-tos --preferred-chain ISRG Root X1
usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: --preferred-chain ISRG Root X1
obtain-and-deploy-letsencrypt-cert.sh: error: The certificate cannot be obtained with '/usr/bin/certbot' tool.
certbot --version
certbot 0.31.0
@VojtechMyslivec: when checking new cert on my "good server" above, I still see the old expired root cert in the chain. Common name: DST Root CA X3 Organization: Digital Signature Trust Co. Valid from September 30, 2000 to September 30, 2021 Serial Number: 44afb080d6a327ba893039862ef8406b Signature Algorithm: sha1WithRSAEncryption Issuer: DST Root CA X3
@rfc4711
It seems the root cert for staging environment changed as well (#71). I haven't check that PR yet.
About the production one and according to the output, your certbot is version 0.31, which is pretty old. You would need at least version >=1.6.
@zimico please check the certbot ($letsencrypt
) path in letsencrypt-zimbra.cfg
and run
sudo -iu zimbra
source /opt/letsencrypt-zimbra/letsencrypt-zimbra.cfg
"$letsencrypt" --version
/opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -V
(on both server probably).
PS: were zimbra services restarted as expected?
The "good server":
[root@zmail01 /]# sudo -iu zimbra
[zimbra@zmail01 ~]$ source /opt/letsencrypt-zimbra/letsencrypt-zimbra.cfg
[zimbra@zmail01 ~]$ "$letsencrypt" --version
certbot 1.11.0
[zimbra@zmail01 ~]$ /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -V
letsencrypt-zimbra version 0.5.1
The "bad server":
[root@sm02 ~]# sudo -iu zimbra
[zimbra@sm02 ~]$ source /opt/letsencrypt-zimbra/letsencrypt-zimbra.cfg
[zimbra@sm02 ~]$ "$letsencrypt" --version
certbot 1.11.0
[zimbra@sm02 ~]$ /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -V
letsencrypt-zimbra version 0.5.1
Sorry I forgot your question. in "good server" I could restart zimbra without any issue. But in "bad server" I had to disable tls support in order to restart zimbra.
zmlocalconfig -e ssl_allow_untrusted_certs=true
zmlocalconfig -e ldap_starttls_supported=0
zmlocalconfig -e ldap_starttls_required=false
zmlocalconfig -e ldap_common_require_tls=0
@rfc4711
It seems the root cert for staging environment changed as well (#71). I haven't check that PR yet.
About the production one and according to the output, your certbot is version 0.31, which is pretty old. You would need at least version >=1.6.
Thank you @VojtechMyslivec, I'm running ubuntu 16.04 xenial on a lxc container and upgrade to the new certboot has proven challenging so far with both methods on pip3 or snap install.
@zimico you need to checkout the branch chain
in the letsencrypt-zimbra git repository. The proposed changes in #73 are not yet merged to master
(I tried to explain that in my message above).
try:
cd /opt/letsencrypt-zimbra/
git checkout chain
and then force-renew the cert
sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -fv
@rfc4711 sadly, Ubuntu 16 is pretty old and certbot 1.6 was released in 2010, 4 years after Ubuntu 16. I am afraid It won't be easy and I am not able to help you with that :frowning_face:
Ubuntu 18.04 bionic is mentioned as "supported" version for Zimbra 8.8 and I am able to install both Zimbra and certbot (via pip) in Ubuntu 18. An upgrade to Ubuntu 18 would be probably the solution (make sure you have a consistent backup system and Zimbra before you perform the update).
@rfc4711 sadly, Ubuntu 16 is pretty old and certbot 1.6 was released in 2010, 4 years after Ubuntu 16. I am afraid It won't be easy and I am not able to help you with that ☹️
Ubuntu 18.04 bionic is mentioned as "supported" version for Zimbra 8.8 and I am able to install both Zimbra and certbot (via pip) in Ubuntu 18. An upgrade to Ubuntu 18 would be probably the solution (make sure you have a consistent backup system and Zimbra before you perform the update).
@VojtechMyslivec thank you, I understand. The de-install from the ppa version had wreaked havoc on my python install. I managed to fix python pip3 and installed the new certbot via pip. Now I got to wait a week to renew since I hit the 5 letsencrypt limit :(.
Nevertheless, off-topic here, however any good upgrade/migration instructions/links/tips from Zimbra 8 on xenial to bionic? I tried on a backup to do-upgrade but that broke Zimbra.
Dear @VojtechMyslivec , thank for your guide. Unfortunately, we have the same result.
[root@sm02 letsencrypt-zimbra]# git branch
* master
[root@sm02 letsencrypt-zimbra]# git checkout chain
Branch chain set up to track remote branch chain from origin.
Switched to a new branch 'chain'
[root@sm02 letsencrypt-zimbra]# sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -fv
...
obtain-and-deploy-letsencrypt-cert.sh: info: start nginx
obtain-and-deploy-letsencrypt-cert.sh: info: assemble cert files
obtain-and-deploy-letsencrypt-cert.sh: info: test and deploy certificates
obtain-and-deploy-letsencrypt-cert.sh: error: Verification of the issued certificate failed.
Manually verify the cert:
[zimbra@sm02 tmp.QrkGdWXhWN]$ zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key 0000_cert.pem chain.pem
** Verifying '0000_cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'
Certificate '0000_cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.
** Verifying '0000_cert.pem' against 'chain.pem'
ERROR: Unable to validate certificate chain: 0000_cert.pem: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup:unable to get issuer certificate
Regards.
chain.pem
should be exactly as chain.pem.txt (one pem
file with two certificates).
You can decode these two certificates with command:
openssl x509 -noout -subject -issuer -dates
and paste the data from the chain.pem
. Output for the first one should look like:
subject=C = US, O = Let's Encrypt, CN = R3
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
notBefore=Sep 4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT
and for the second:
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
notBefore=Jun 4 11:04:38 2015 GMT
notAfter=Jun 4 11:04:38 2035 GMT
zmcertmgr verifycrt
returns OK in my case.
PS: don't you forget to fetch/pull the upstream version? You could stick on some older chain
branch variant.
git checkout chain
git pull --rebase
The top commit of the chain
branch is currently 6e02984c
Nevertheless, off-topic here, however any good upgrade/migration instructions/links/tips from Zimbra 8 on xenial to bionic? I tried on a backup to do-upgrade but that broke Zimbra.
@rfc4711 I would ask at Zimbra forum
Dear @VojtechMyslivec , Thank for your kind support with git because I do not know much about git.
[root@zmail01 letsencrypt-zimbra]# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/chain
remotes/origin/gitlab
remotes/origin/master
remotes/origin/request-tweaks
[root@zmail01 letsencrypt-zimbra]# git checkout chain
Branch chain set up to track remote branch chain from origin.
Switched to a new branch 'chain'
[root@zmail01 letsencrypt-zimbra]# git pull --rebase
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 3), reused 5 (delta 3), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/VojtechMyslivec/letsencrypt-zimbra
e0ebe09..3f57ff0 chain -> origin/chain
First, rewinding head to replay your work on top of it...
Fast-forwarded chain to 3f57ff067b595622f7a5ae7a6a2dfb4aede30944.
[root@zmail01 letsencrypt-zimbra]# sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and -deploy-letsencrypt-cert.sh -V
letsencrypt-zimbra version 0.6
[root@zmail01 letsencrypt-zimbra]# git log -n 1
commit 3f57ff067b595622f7a5ae7a6a2dfb4aede30944
Author: Vojtech Myslivec <vojtech@xmyslivec.cz>
Date: Thu Oct 7 19:18:01 2021 +0200
fixup! Install certbot via pip by default
The renewal still failed with obtain-and-deploy-letsencrypt-cert.sh
: error: Verification of the issued certificate failed.
I see that our chain.pem
includes 3 certs:
The first one:
subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
notBefore=Sep 4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT
The second one:
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
notBefore=Jan 20 19:14:03 2021 GMT
notAfter=Sep 30 18:14:03 2024 GMT
The third one:
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
notBefore=Jun 4 11:04:38 2015 GMT
notAfter=Jun 4 11:04:38 2035 GMT
Could you please check why our script create this kind of chain.pem
file?
Thank you.
Don't you have some local changes in the repo?
git status
git diff
how does your letsencrypt-zimbra.cfg
look like? You should have letsencrypt_altchain
parameter unset or set to true
. See letsencrypt-zimbra.cfg.example
.
Thank for your advice. This is maybe the cause. My cfg file does not have this:
# Issue a cert with "ISRG Root X1" preferably. Change it to false if you
# want to use the Let's Encrypt default (and expired) "DST Root CA X3"
#letsencrypt_altchain="true"
I haven't made any change in the repo, just follow your guide:
[root@zmail01 letsencrypt-zimbra]#git checkout chain
[root@zmail01 letsencrypt-zimbra]#git pull --rebase
[root@zmail01 letsencrypt-zimbra]# git status
# On branch chain
nothing to commit, working directory clean
[root@zmail01 letsencrypt-zimbra]# git diff
(empty result)
Regards, Minh.
That should be fine. letsencrypt_altchain="true"
is the default value.
Based on the list of certs in previous comment, I guess that there is some issue in certbot
. When you run obtain-and-deploy-letsencrypt-cert.sh -fv
, you should see certbot_extra_args
value and it should contain --preferred-chain "ISRG Root X1"
. Is that correct? (You have stripped it from the output previously).
Dear @VojtechMyslivec , I rerun the script and see there is --preferred-chain ISRG Root X1
option. (Without double quote "ISRG Root X1").
[root@zmail01 letsencrypt-zimbra]# sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -vf
obtain-and-deploy-letsencrypt-cert.sh: info: Running in force mode, certificate will be renewed.
obtain-and-deploy-letsencrypt-cert.sh: info: create csr config '/tmp/tmp.7cjiXxtNL6/openssl.cnf'
obtain-and-deploy-letsencrypt-cert.sh: info: generate csr '/tmp/tmp.7cjiXxtNL6/request.pem'
obtain-and-deploy-letsencrypt-cert.sh: info: stop nginx
obtain-and-deploy-letsencrypt-cert.sh: info: issue certificate; certbot_extra_args: --non-interactive --agree-tos --preferred-chain ISRG Root X1
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Server issued certificate; certificate written to /tmp/tmp.7cjiXxtNL6/0000_cert.pem
Cert chain written to <fdopen>
Cert chain written to <fdopen>
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/tmp/tmp.7cjiXxtNL6/0001_chain.pem
Your certificate will expire on 2022-01-09. To obtain a new or
tweaked version of this certificate in the future, simply run
certbot again. To non-interactively renew *all* of your
certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
obtain-and-deploy-letsencrypt-cert.sh: info: start nginx
obtain-and-deploy-letsencrypt-cert.sh: info: assemble cert files
obtain-and-deploy-letsencrypt-cert.sh: info: test and deploy certificates
obtain-and-deploy-letsencrypt-cert.sh: error: Verification of the issued certificate failed.
Dear @VojtechMyslivec I see in the https://serverfault.com/questions/1075514/how-to-fix-certificate-chain-with-letsencrypt-certbot
As note for such old installations Cross-Signed Let’s Encrypt R3 and DST Root CA X3, intermediate and root certificates will expire on Sep 29, 2021 and Sep 30, 2021 respectively. So since May 4, 2021, The newly issued certificates use a longer chain with cross-signed ISRG Root X1 as an intermediate certificate.
Unfortunately, due to the way certificate paths are built and verified, not all implementations of TLS can successfully verify the cross-sign. This is the case with OpenSSL 1.0.2. Hence, programs running on RHEL/CentOS 7 that use OpenSSL will likely fail to verify the new certificate chain or establish TLS connection. Upgrading to newer Openssl versions on such platforms is not straightforward.
There are a few options: either update the trust store (remove DST Root CA X3 root certificate - once it is removed, impact should be minimal) on the client side (or) change the certificate chain on the server side.
My openssl version:
[root@zmail01 letsencrypt-zimbra]# openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
OpenSSL version shouldn't be the problem zimbra verify command verify exactly the chain provided and don't care about cert store.
The issue is that certbot
generates a chain with DST Root
, although instructed differently. Would you check /var/log/letsencrypt/letsencrypt.log
for any details, please? You can send the logs privately to my e-mail address (accessible e.g. in commit messages).
Please note that I just merged @jogerj #71 patches to make testing/staging environment available. You can test renewal with -t
from current chain
version. Please pull the changes or download the latest zip and rerun it with -f
, -t
and -v
sudo -iu zimbra /opt/letsencrypt-zimbra/obtain-and-deploy-letsencrypt-cert.sh -ftv
Thank you for the log you sent me privately. I haven't find anything relevant. Everything seems to work as expected, but in the end, you end up with DST root instead of ISRG one :disappointed:
However, I made some other investigation on Let's Encrypt community forum and I found 2 similar topics:
All your, @mpricu and these topics above have similar things: CentOS and certbot 1.19.0
I am pretty sure that the issue is in CentOS certbot
package. Based on the info provided in comment, the fix is on the way in epel-testing
(whatever it means).
A quick workaround could be to install certbot
via pip (where version 1.20.0
is present), but I can't guide you more as I am not skilled in CentOS nor have one to test and play with.
Dear,
Thank you very much for your time and value info. At least I know that I need to upgrade certbot now to see if it can fix my issue.
Have a nice day!
My warmest regards, Zimico
Thank you, I tried to update certbot using epel-testing repo on Centos 7 and now can renew my certs successfully.
perfect :+1:
@VojtechMyslivec, I pulled also the chain branch and verified that the test and production certificates install perfectly. The release I used is Ubunutu 18.04 bionic.
In case someone comes across this, my upgrade journey from ubuntu 16.04 to 18.04 and also upgrading zimbra to the latest 8.8.15:
1) Upgrade Ubuntu: https://wiki.zimbra.com/wiki/Ubuntu_Upgrades Scroll down to upgrade ubuntu 16 to 18. As last step run /opt/zimbra/libexec/zmsetup.pl
2) Fix permissions: (https://forums.zimbra.org/viewtopic.php?t=66709&start=10)
###
su - zimbra
export PERL5LIB=/opt/zimbra/libexec/scripts:$PERL5LIB
cd /opt/zimbra/libexec/scripts/
./migrate20190401-ZimbraChat.pl
./migrate20190611-ZimbraChat.pl
#####
zimbra@zimbra:zmlocalconfig -e mailboxd_java_options="-server -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.awt.headless=true -XX:+UseG1GC -Dsun.net.inetaddr.ttl=${networkaddress_cache_ttl} -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=15 -XX:G1MaxNewSizePercent=45 -XX:SoftRefLRUPolicyMSPerMB=1 -XX:-OmitStackTraceInFastThrow -verbose:gc -Xlog:gc*=info,safepoint=info:file=/opt/zimbra/log/gc.log:time:filecount=20,filesize=10m -Djava.net.preferIPv4Stack=true -XX:+HeapDumpOnOutOfMemoryError -XX:CompileCommandFile=.hotspot_compiler -XX:HeapDumpPath=/opt/zimbra/log -XX:ErrorFile=/opt/zimbra/log/hs_err_pid%p.log"
Very nice. Thank you for the info
Dear, Today (1-Oct-2021), our users report that Kaspersky antivirus software blocks them accessing the zimbra webmail because of "This certificate cannot be verified up to a trusted certification authority". Our letsencrypt cert is issued by ISRG Root X1 / R3 and valid from 01-Oct-2021 to 30-Dec-2021
Best regards, Minh.