SSLSetup on Amazon Linux: SSL Error, Multiple certificates provided

Question

I have setup an Amazon Linux EC2 instance to host my domain. I am using a certificate signed by letsencrypt.org.

I generated my certificate:

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
sudo ./certbot-auto --debug -v --server https://acme-v01.api.letsencrypt.org/directory certonly -d <mywebsite.com>

Enabled ssl in apache:

sudo yum install mod24_ssl

And made the following changes to my apache configuration:

SSLCertificateFile      /etc/letsencrypt/live/<mydomain.com>/cert.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/<mydomain.com>/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/<mydomain.com>/chain.pem

When visiting mydomain.com I get the following message:

NET::ERR_CERT_AUTHORITY_INVALID
Subject: ip-172-31-37-151
Issuer: avast! Web/Mail Shield Self-signed Root
Expires on: Feb 16, 2018
Current date: Feb 16, 2017
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIIEYDCCA0igAwIBAgIQQxnowUTk2EGGE/O409WnvzANBgkqhkiG9w0BAQsFADCB
mDFDMEEGA1UECww6Z2VuZXJhdGVkIGJ5IGF2YXN0ISBhbnRpdmlydXMgZm9yIHNl
bGYtc2lnbmVkIGNlcnRpZmljYXRlczEfMB0GA1UECgwWYXZhc3QhIFdlYi9NYWls
IFNoaWVsZDEwMC4GA1UEAwwnYXZhc3QhIFdlYi9NYWlsIFNoaWVsZCBTZWxmLXNp
Z25lZCBSb290MB4XDTE3MDIxNjE3NTgwN1oXDTE4MDIxNjE3NTgwN1owgbExCzAJ
BgNVBAYTAi0tMRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5
MRkwFwYDVQQKDBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5p
emF0aW9uYWxVbml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMzctMTUxMSQwIgYJKoZI
hvcNAQkBFhVyb290QGlwLTE3Mi0zMS0zNy0xNTEwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCVUjj4IziKclAqMWktKeq+lWPP0Jfo09a35xhQ08+A/n8k
ToB8oZosYwDLuQDV3kNYCJ03eq2EK3/JwU59uBGU217l4YrG4p93RnRRtV1vp+Au
+kxUlkuMx2yvz2M49ZHd44D7LOOB/V0wsnHQBHRS7iECfz4M+J6QWef4oMwP9mue
T8xJUst0N7mfekBBIAZOIpYjbcm4Nbq3Ol3S5AHd3VP3AbQr0MqHjciXx9Hf1ejt
1o0b96w0feEIZOcESYlwHK5Nl0hvS3WHZww4haAKPQVJxaH6XuMN54rB2Gt/oxhK
iHbBfjdgAanjvK8vab41n2krnaWU8gKIKp0JGjwbAgMBAAGjgYowgYcwDAYDVR0T
BAUwAwEB/zBqBgNVHREEYzBhgglsb2NhbGhvc3SCFWxvY2FsaG9zdC5sb2NhbGRv
bWFpboIQaXAtMTcyLTMxLTM3LTE1MYIraXAtMTcyLTMxLTM3LTE1MS51cy13ZXN0
LTIuY29tcHV0ZS5pbnRlcm5hbDALBgNVHQ8EBAMCAuQwDQYJKoZIhvcNAQELBQAD
ggEBABgX4vyY9XT7tGKv7HKRlTAZQ218e1fPIx9Y2+TeeJFoujE0QhDysVOB2tww
tqeuaXBnSoUini5pgWQZG8xUBiAu1ZHpFn7X3CSzU6WP9OlseGZolXcXEt7KopHv
Mk8RhHSIOyF3Z6CQvAjUbp4hvqNU4oXbcE9vBjWa8VhiFWJMH3GI645Zc3oICvKs
XziFc09haDk9yV/4dqec34xJLSUX4rWxmZX92l3pEjZwR7bXZRqWnt5IwDbxaswj
QwsEWJigOs2ZbHw2g8mESqbNpnbgxKOuMWxe1WxjBUYbGHfHQROb1COaDIANgqDW
PFjpaWnE/WwSOwvxRhxe0ETCY9Q=
-----END CERTIFICATE-----

It looks like my domain is providing a self signed certificate and not the one from letsencrypt.org. An analysis on ssllabs.com shows my that two certificates are being provided by my domain. A self signed certificate that I did not create as well as the one from letsencrypt.org.

How do I get rid of this self signed certificate and where is it coming from?

Val Kornea · Answer 1 · 2017-10-23T11:15:05.777

I hate editing the original conf files, so I just spent a few hours figuring out the right way to do this. According to the apache documentation:

Name-based virtual hosts for the best-matching set of <virtualhost>s are processed in the order they appear in the configuration. The first matching ServerName or ServerAlias is used, with no different precedence for wildcards (nor for ServerName vs. ServerAlias).

If you look inside /etc/httpd/conf.d/ssl.conf you will see that it defines a <VirtualHost> section without a ServerName (pasted below). From observation, all :443 requests that haven't matched a ServerName or ServerAlias by the time ssl.conf is read will match this section, but the fact that this section matches doesn't prevent other sections from matching as well (since this section has no ServerName). Therefore, if we define our <VirtualHost>s within a file that is read after ssl.conf, we will end up including two certs. The way around this is to make sure to define all <VirtualHost>s with a ServerName in a file which comes alphabetically before ssl.conf, such as /etc/httpd/conf.d/aa_example.conf. If a <VirtualHost> with a ServerName has already matched by the time apache parses ssl.conf, its default <VirtualHost> will no longer qualify as a match.

##
## 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.
#   Disable SSLv3 by default (cf. RFC 7525 3.1.1).  TLSv1 (1.0) should be
#   disabled as quickly as practical.  By the end of 2016, only the TLSv1.2
#   protocol or later should remain in use.
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3

#   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.
# By leaving this directive commented out, the system-wide OpenSSL
# default is used.  See update-crypto-policies(8) for more details.
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
#SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

#   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

This is a lucid explanation and did solve the issue for me. – rtviii Jun 09 '21 at 02:58 — rtviii, Jun 09 '21 at 02:58

score 0 · Answer 2 · edited May 23 '17 at 11:54

A few things to think about:

1) Make sure you restarted apache after the changes.

2) Use openssl or other tools to inspect the certificate.pem and chain.pem files - do they have more than one certificate?

openssl x509 -in certificate.pem -text

3) Perhaps you have more than one virtual server configured in apache and your calls from the browser are being routed to the wrong one.

4) Do the apache log files give you any further clue as to what is going on?

I had a problem like this before with multiple named-based virtual servers that were not routing correctly. I ended up using port-based routing to solve that particular problem.

It turns out that a default self signed certificate was created and and set in `ssl.conf` when I installed `mod24_ssl`. I have posted an answer. — Maverik Minett, Feb 16 '17 at 20:51

score 0 · Accepted Answer · answered Feb 16 '17 at 20:49

Running grep -rnw '/etc/httpd/.' -e "SSLCertificateFile" showed that a security certificate was also being set in the file /var/httpd/conf.d/ssl.conf. I commented out the lines in this file and everything is working as expected.

./conf/httpd.conf:357:        SSLCertificateFile      /etc/letsencrypt/live/codewise.tech/cert.pem
./conf/httpd.conf:376:  SSLCertificateFile      /etc/letsencrypt/live/codewise.tech/cert.pem
./conf.d/ssl.conf:94:# Point SSLCertificateFile at a PEM encoded certificate.  If
./conf.d/ssl.conf:98:#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
./conf.d/ssl.conf:111:#   the referenced file can be the same as SSLCertificateFile

SSLSetup on Amazon Linux: SSL Error, Multiple certificates provided

3 Answers3