Browsers don't recognize renewed certificate

I have renewed the certificate many times before, but this time browsers don't recognize the new one. I am pretty non-expert at this. Thanks for any help!

My domain is: travelintaiwan.net

I ran this command: certbot --force-renewal

It produced this output: Your existing certificate has been successfully renewed, and the new certificate has been installed.

My web server is (include version): Apache 2.4.54

The operating system my web server runs on is (include version): Centos 7

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.11.0

Well, forcing a renewal with --force-renewal won't fix that issue, but will increase the load on the LE servers and might make you hit rate limits. So please don't use that option if you have no clue what it actually does.

Please share the output of the command sudo certbot certificates and the command sudo apachectl -t -D DUMP_VHOSTS

4 Likes

Thanks for your reply!

sudo certbot certificates:

Found the following certs:
Certificate Name: travelintaiwan.net
Serial Number: 37fce27cf5e66445f7ae94a8f32cf0804a6
Key Type: RSA
Domains: travelintaiwan.net www.travelintaiwan.net
Expiry Date: 2023-05-30 06:27:51+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/travelintaiwan.net/fullchain.pem
Private Key Path: /etc/letsencrypt/live/travelintaiwan.net/privkey.pem

sudo apachectl -t -D DUMP_VHOSTS:

VirtualHost configuration:
*:443 is a NameVirtualHost
default server www.travelintaiwan.net (/etc/httpd/conf.d/ssl.conf:58)
port 443 namevhost www.travelintaiwan.net (/etc/httpd/conf.d/ssl.conf:58)
port 443 namevhost travelintaiwan.net (/etc/httpd/conf.d/travelintaiwan-le-ssl.conf:2)
alias www.travelintaiwan.net
*:80 travelintaiwan.net (/etc/httpd/conf.d/travelintaiwan.conf:1)

This looks fine.

Potentialle there is a conflict between or misconfiguration regarding certificates in these two configuration files. Please show the contents of /etc/httpd/conf.d/ssl.conf as well as /etc/httpd/conf.d/travelintaiwan-le-ssl.conf.

4 Likes

There have been certificates issued letsdebug-toolkit, the latest being 01 Mar 2023 06:27:52 UTC.

Yet the certificate being served is EXPIRED!
https://www.ssllabs.com/ssltest/analyze.html?d=travelintaiwan.net

$ openssl s_client -showcerts -servername travelintaiwan.net -connect travelintaiwan.net:443 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = travelintaiwan.net
verify error:num=10:certificate has expired
notAfter=Feb 19 02:20:36 2023 GMT
verify return:1
depth=0 CN = travelintaiwan.net
notAfter=Feb 19 02:20:36 2023 GMT
verify return:1
---
Certificate chain
 0 s:CN = travelintaiwan.net
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov 21 02:20:37 2022 GMT; NotAfter: Feb 19 02:20:36 2023 GMT
-----BEGIN CERTIFICATE-----
MIIFQTCCBCmgAwIBAgISBGCOceZv6RDuBpWAYV5g+CpCMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjExMjEwMjIwMzdaFw0yMzAyMTkwMjIwMzZaMB0xGzAZBgNVBAMT
EnRyYXZlbGludGFpd2FuLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMC0VmCvcVZAGyNunIOJhxUMIQY/9Mi2ohrWfsQwrqdJ5CBoeG34mBFifdJ2
0kR94TIhKGqbUIL2gnhm37JJFLAAzc1LN7tQ67mDN7PSPYXOahxEGzwa70MgFWsG
3MPBXkE1FFtK2MO6keTWBZbr61ol2XkvS58GGaUeeNRSqDt4pSGXpb3RI9/jGmPF
Sy9TnoKfOtzLoZF3Y3UVitK0VYQ7aUjYCRZvPyQG4fTk6B6xBC7q3t//wwqCB9/y
D989UAyhOFYceEyTE8z3eEpQdpJLUgtLDk0mLFUbihV47iZwlYUmmMhnKXWTagOO
yfcJQCsvDDipG8xzHnmPMvuhAUUCAwEAAaOCAmQwggJgMA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAd
BgNVHQ4EFgQUYAQdYHhJwbdn9D/LORqmGx9UGacwHwYDVR0jBBgwFoAUFC6zF7dY
VsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRw
Oi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNy
Lm9yZy8wNQYDVR0RBC4wLIISdHJhdmVsaW50YWl3YW4ubmV0ghZ3d3cudHJhdmVs
aW50YWl3YW4ubmV0MEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEB
MCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYK
KwYBBAHWeQIEAgSB9ASB8QDvAHYAtz77JN+cTbp18jnFulj0bF38Qs96nzXEnh0J
gSXttJkAAAGEmDO6ywAABAMARzBFAiEAgl/UvQ51XkoIz83fvzo0o4ZyZ73C7n0N
uD7ghISByFsCIBcGbm7iFR4RDHW3ZVeK9srhpzv20nwcLbF8ZtGLqcODAHUArfe+
+nz/EMiLnT2cHj4YarRnKV3PsQwkyoWGNOvcgooAAAGEmDO85gAABAMARjBEAiAt
NGOH3GzEm7tfKbNBH+W2VLxkuHQN/RcexSTrYDOjFQIgPCN023PAu0rC9DBR8Ut3
cF+B7LtNUtrgkq6Ut81a9AswDQYJKoZIhvcNAQELBQADggEBAJD38iWijAbF+Ori
ETHDle9ZxKXr3oc+YVXHu+J0eNEQmdsHgzzK71ZAVNROwn528E35rY3NxCpxMihj
Je8KsDGzsRS1KmIh5JEPg9nGaGymCe8ybubOKDmtyphQV7mYtFWLpHP9x8Y59AMW
wdUEsEXnWNjSTF3zwTjIUT629881kDKUKyECkqkaH1ZpZkXM0Kt3lGBUZPYRKNHu
abAvP/gCgFlaElbX3djLpyLSajCNLGLmuO+HSOgftVveWc3xZFoW3+ScQHyDTEZZ
z25eoVgpcjUHJ7ZbHe4cR6kwp/WOWNP1v0Hai9Q19lvZGW1VvM5hkBo1389fC080
cuUQIUw=
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
---
Server certificate
subject=CN = travelintaiwan.net
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4550 bytes and written 446 bytes
Verification error: certificate has expired
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 2DA9E61AB05C0AEE7451409F78841357D03B4D054CF2FE537E7F80B109D42326
    Session-ID-ctx:
    Master-Key: 618714DB652267B7C82A76F9E803A9339E370277A4C57A0D673DBAA399AF073EC17AA2F55A29F7F384C5E08844F8EAE3
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1677709675
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: yes
---
DONE

Did you restart Apache?

2 Likes

Have you fixed the name:port overlap?

3 Likes

Sorry for the late reply. Living in a different time zone. Also, can't access server right now.

But thanks so far for the help. I will try the suggestions.

2 Likes

I did restart a few times. Today, finally it went through! Thanks for your helps and suggestions!!!

3 Likes

Wait a minute. Yesterday it was fine. Today, I get the dreaded "This connection is not secure" message again. What is going on? :unamused:

The cert being served expired 11 days ago.

3 Likes

Here is the content of /etc/httpd/conf.d/ssl.conf

# When we also provide SSL we have to listen to the
# standard HTTPS port in addition.
#
Listen 443 https

Protocols h2 http/1.1

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the
#   SSL library. The seed data should be of good random quality.
#   WARNING! On some platforms /dev/random blocks if not enough entropy
#   is available. This means you then cannot use the /dev/random device
#   because it would lead to very long connection times (as long as
#   it requires to make more entropy available). But usually those
#   platforms additionally provide a /dev/urandom device which doesn't
#   block. So, if available, use this one instead. Read the mod_ssl User
#   Manual for more details.
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512
#SSLRandomSeed connect file:/dev/urandom 512

#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443

# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   List the protocol versions which clients are allowed to connect with.
#   The OpenSSL system profile is configured by default.  See
#   update-crypto-policies(8) for more details.
SSLProtocol +TLSv1.2 +TLSv1.3
SSLProxyProtocol +TLSv1.2 +TLSv1.3

#   User agents such as web browsers are not configured for the user's
#   own preference of either security or performance, therefore this
#   must be the prerogative of the web server administrator who manages
#   cpu load versus confidentiality, so enforce the server's cipher order.
SSLHonorCipherOrder on

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
#   The OpenSSL system profile is configured by default.  See
#   update-crypto-policies(8) for more details.
SSLCipherSuite "EECDH+AES128:EECDH+AES256:+SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RSA+3DES:!DSS"
SSLProxyCipherSuite "EECDH+AES128:EECDH+AES256:+SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RSA+3DES:!DSS"

#   Point SSLCertificateFile at a PEM encoded certificate.  If
#   the certificate is encrypted, then you will be prompted for a
#   pass phrase.  Note that restarting httpd will prompt again.  Keep
#   in mind that if you have both an RSA and a DSA certificate you
#   can configure both in parallel (to also allow the use of DSA
#   ciphers, etc.)

#   Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
#   require an ECC certificate which can also be configured in
#   parallel.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
#   ECC keys, when in use, can also be configured in parallel
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convenience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10

#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<Location />
#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
#            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
#           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>

#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is sent or allowed to be received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is sent and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly.
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

Here is the content of /etc/httpd/conf.d/travelintaiwan-le-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin [abc]
DocumentRoot "/var/www/html/"
ServerName travelintaiwan.net
ServerAlias www.travelintaiwan.net
ErrorLog "/var/log/httpd/travelintaiwan.net-error_log"
CustomLog "/var/log/httpd/travelintaiwan.net-access_log" combined

<Directory "/var/www/html/">
DirectoryIndex index.html index.php
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/travelintaiwan.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/travelintaiwan.net/privkey.pem
</VirtualHost>
</IfModule>

Please let me know if there is anything wrong there. Thanks a lot!!

How do I fix that?

This isn't the place for basic web server configuration advice.
But since you asked so nicely... here's some free tips:

  • if you are not using the ssl.conf file, then don't use it.
  • if you must use it, then at least put a "non-conflicting" server name in it:
  • You shouldn't use a ServerName in the main config that will be served in any other config.
    [look for ServerName in the main config and change it to something you can't serve over the Internet - like: "localhost"]

And also show the output of:
certbot certificates

5 Likes

Here https://decoder.link/sslchecker/travelintaiwan.net/443 and here https://decoder.link/sslchecker/www.travelintaiwan.net/443 are still showing Expired: Yes (expired 14 days ago); while the latest issued certificate was on 2023-03-01 crt.sh | travelintaiwan.net
@twellit you still have issues to resolve.

1 Like

I know. Can I just delete the existing certificate and install it from scratch?

"certbot certificates" show this:

Found the following certs:
  Certificate Name: travelintaiwan.net
    Serial Number: 34b6f0e3fd2627805bcb109828c1533569b
    Key Type: RSA
    Domains: travelintaiwan.net www.travelintaiwan.net
    Expiry Date: 2023-06-04 03:54:57+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/travelintaiwan.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/travelintaiwan.net/privkey.pem

1 Like

Why delete a perfectly good cert?

3 Likes

Because it is not recognized by the browsers?

I just want to know why it was working perfectly for two years, and now it is not. We didn't make any changes, I believe.

Then you/we/someone needs to figure out exactly why that is happening.
Deleting that cert and getting a new one will only return you right back to this same spot.
[and waste a perfectly good cert]

3 Likes

That's not the fault of the certificate. So deleting it makes no sense.

5 Likes