Hi folks, I’m sorry this is probably an easy question but I can’t seem to figure out a definitive answer and I’ve never had to configure https/SSL before. Apache 2.2.15 on CentOS 6.8.
When I generate my certificate I do it for www.(example).org.uk and (example).org.uk, but my server has been set up by the university I work with (using some custom scripts) and is therefore set up on the local network as (name).(dept).(uni).ac.uk. The errors are fairly obvious:
(example).org.uk uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
The certificate is not valid for the name (example).org.uk.
My questions, and thank you in advance! -
Will the self-signed error go once Centos and Apache are set up correctly?
As well as changing /etc/sysconfig/network, I need to do something with /etc/hosts but I’m not sure what the right formatting would be? I’ve tried changing both of these and restarting the network service but hostname is still (name).(dept).(uni).ac.uk - what else do I need to change, and will this then effect the local network address? Is there any way I can do it so that any IT tasks that are set up can still access (name).(dept).(uni).ac.uk? Thank you again.
Hi @kab, I'm not quite sure what you're referring to in terms of "set up on the local network as" here. I guess you're saying that the name.dept.uni.ac.uk version is the canonical version assigned by your university, and also the internal hostname that your server gets from DHCP, but not the name that you prefer to use when accessing the server?
It sounds like the error that you're seeing means that the cert that you got from Let's Encrypt is not yet installed properly. Once it's installed, the certificate should match.
This part is kind of unclear to me in terms of whether you want to change how your computer thinks of itself or how other computers on the LAN refer to it. There's not usually a problem with different users referring to the same server under different names (for example, at big hosting providers a single server can answer requests for thousands of different sites, often using just a single IP address which each of those site's domain names resolves to in the DNS). While there can be a difficulty with certificate mismatches, I assume that nobody is currently accessing any HTTPS service on name.dept.uni.ac.uk under that name, right?
Thanks for your reply, and sorry that I'm so confused about how this should work! I'll redact the actual details later but for now it's probably easier if I use the actual names. The hosting server is called kelpie and is hosted on the arts.gla.ac.uk subdomain - it uses DNS. The site is opencollections.org.uk so my command is: ./certbot-auto --apache -d opencollections.org.uk -d www.opencollections.org.uk
Basically I'm trying to figure out where the certificate generation is getting kelpie from instead of opencollections.org.uk. I'm thinking now I've been entirely confused in changing CentOS settings, and it's actually something in Apache? I don't know what set-up was done before I could access the server, but apache is serving out some pages that are under a kelpie.arts.gla.ac.uk, nothing with https however, and nothing that I need to keep.
Thank you so much again for any help you can give and sorry about my lack of understanding.
The reason for the trouble is that your server is configured to use an existing certificate for kelpie.arts.gla.ac.uk, which is self-signed (not issued by a publicly-trusted CA) and does not mention opencollections.org.uk at all. The existing certificate could not have been created by Certbot or as a direct result of your attempt to use Certbot, but must have existed before.
What’s more, assuming that you’ve been trying to set this up today or in the last few days, you’ve apparently so far not succeeded in getting a cert from Let’s Encrypt at all
So Certbot probably didn’t run or didn’t succeed for some reason, and the problems that you’re seeing relate to that, rather than to the existence of different names that refer to the same server.
Can you tell us about the output or logs that were produced when you tried to run certbot-auto?
Thanks @schoen, the basic certbot output indicated everything was successful:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for opencollections.org.uk
tls-sni-01 challenge for www.opencollections.org.uk
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem
Deploying Certificate to VirtualHost /etc/httpd/conf.d/opencollections.org.uk-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/opencollections.org.uk-le-ssl.conf
...
Your existing certificate has been successfully renewed, and the new certificate
has been installed.
The new certificate covers the following domains: https://opencollections.org.uk
and https://www.opencollections.org.uk
The debug logs don't indicate anything failing, anything referencing the server or uni subdomain. The previous certificate expired today iirc, and had the same issue.
ETA: I don't see any certificates for kelpie, or any apache config for it, but I do see config for opencollections.
Yeah I saw that previous certificate, but I don't understand why it hasn't updated since I used the same command and got the same issues with the expired one!
The command output:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:17:96:cb:b2:f9:c9:d7:37:c3:3d:4d:fc:bc:99:a8:6f:b0
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Feb 1 22:46:00 2017 GMT
Not After : May 2 22:46:00 2017 GMT
Subject: CN=opencollections.org.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a6:83:f3:c6:99:ac:a1:bd:3a:2e:6d:4c:a4:bd:
6f:f5:ce:d4:08:ff:de:ef:a4:aa:56:2a:3e:d0:75:
47:c7:51:4b:ae:6b:a0:19:ab:3c:a0:bc:3e:29:77:
75:d3:f9:1b:3b:9d:f0:4d:b3:e8:bb:c8:4b:89:c7:
2f:e5:41:6b:29:c1:87:da:1b:98:8c:f8:ef:ed:03:
f0:e0:04:9e:52:2c:80:77:1d:dc:f7:9c:42:75:e1:
9b:95:1d:e3:e7:35:b3:e6:2f:d1:09:aa:93:d1:45:
40:52:98:3b:0c:9b:9a:81:32:f5:20:69:a2:ab:a9:
0f:47:8a:b9:f7:5d:20:f8:fb:8a:c6:c4:83:98:3a:
a7:b1:c0:98:01:b7:ea:a5:0a:83:f9:07:25:22:38:
06:f9:ef:95:dd:be:19:5d:c8:85:18:4d:18:e8:6a:
52:e9:9d:0a:1e:ab:87:56:13:a5:bc:37:44:bd:c2:
ef:76:0f:8d:07:a4:92:85:43:34:57:6d:1e:ad:d0:
1f:85:9f:fc:b9:47:b6:46:03:41:0b:ef:63:f8:53:
8a:4c:69:80:7e:92:41:be:23:27:d2:9e:06:23:90:
6e:ec:5e:da:a6:0d:88:58:bf:be:9e:c8:e7:3e:7c:
78:be:42:48:0d:05:82:41:05:64:b0:88:eb:bf:c4:
fa:d5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
67:13:D3:31:54:F7:36:31:79:49:6F:AB:A2:E6:62:B0:32:34:88:67
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:opencollections.org.uk, DNS:www.opencollections.org.uk
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the > Certificate Policy found at Policy and Legal Repository - Let's Encrypt
Signature Algorithm: sha256WithRSAEncryption
20:ea:a9:89:ec:3e:96:ce:c2:66:64:1e:8e:59:e4:96:7d:d4:
e8:ae:15:f0:75:08:46:98:9e:33:bd:8d:ec:2a:fb:8b:a3:37:
24:2a:c1:fe:16:8b:49:95:86:22:d0:ab:76:d5:20:8f:62:b2:
ba:4a:0a:4a:b3:0d:2e:39:4e:07:9c:be:ed:fc:e2:c0:6f:a2:
8f:90:c3:94:fc:c6:77:c7:d9:7a:e8:68:dd:1b:0d:33:0c:b4:
c3:19:79:85:8a:47:01:04:d4:35:14:c2:04:96:36:bb:ba:db:
cd:b1:87:6f:51:fa:a6:e9:00:65:44:0b:5f:3a:97:03:fc:f0:
8d:0e:f2:69:c3:5a:d9:4c:af:3a:c0:21:96:6c:2d:82:c1:fb:
de:d2:57:9a:3a:2b:94:ad:34:93:2c:f6:e2:cc:0a:58:3a:a3:
71:38:51:f5:1d:32:f9:a7:81:09:a6:3a:72:67:97:9b:c6:7d:
c0:07:05:a8:c8:b1:1e:e8:45:c0:43:a4:60:ed:85:71:35:5a:
66:02:e3:d0:1a:09:47:41:91:f1:42:90:c2:d1:6f:56:5e:94:
87:37:e9:fe:47:93:50:f8:22:00:83:c7:02:77:86:90:83:90:
28:64:e6:6e:54:1e:34:00:3b:96:ab:f0:91:c5:94:58:62:ea:
b3:95:7b:be
OK! So it looks like you did get the new certs issued successfully, but your web server is simply not configured to use them. (And maybe I was misled by a crt.sh processing delay.) This is very possible because the web server will have a configuration file of some kind pointing to particular cert files and then it will use those in connection with inbound requests.
I see that your server is running Apache, so perhaps you could try
cd /etc/apache2 grep -r SSLCertificate .
That should show which virtual hosts are using a certificate and where that certificate is coming from (I’m going to guess it will turn out to be somewhere other than /etc/letsencrypt).
That’s it! Thank you a million times! in ssl.conf I thought those lines were still commented out, but they were pointing to a self-signed openssl certificate I knew nothing abou! Thank you so much again, and sorry it turned out to be something very simple!