Change CN in certificate after crash recovery

My domain is: hartings.se

I ran this command: certbot-auto --apache – no problems reported
but not “green” https sign is not there.
Also ran: certbot-auto --apache --force-renewal , same result.

It produced this output:
checking certificate on SSL-labs says certificate belongs to “backupserver-hartings-se”, though my domain is hartings.se. A backup computer which acted as replacement server during a crash of my main server (Oct. 9th 2019) was indeed called backupserver.hartings.se and I did request SSL certificate for that server during the time it was active, from Oct 9th. Now I have moved back the repaired server (name server1.hartings.se), but the new certificate in my repaired server says, it is for “backupserver-hartings-se” instead of hartings.se. What should I do to get this right?

My web server is (include version): CENTOS 8 using certbot-auto

The operating system my web server runs on is (include version): Linux CENTOS 8

My hosting provider, if applicable, is: own

I can login to a root shell on my machine (yes or no, or I don’t know): I have physical access to machine

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

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

1 Like

Hi @hartings

checking your domain you see the problem - https://check-your-website.server-daten.de/?q=hartings.se

Domainname Http-Status redirect Sec. G
http://hartings.se/ 155.4.232.9 301 https://hartings.se/ Html is minified: 100,00 % 0.103 A
http://www.hartings.se/ 155.4.232.9 301 https://www.hartings.se/ Html is minified: 100,00 % 0.107 A
https://www.hartings.se/ 155.4.232.9 302 https://hartings.se/ Html is minified: 100,00 % 2.570 B
https://hartings.se/ 155.4.232.9 No GZip used - 29744 / 79713 - 37,31 % possible Inline-JavaScript (∑/total): 6/13667 Inline-CSS (∑/total): 3/5425 200 Html is minified: 135,43 % 2.596 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors

Your www version has the correct certificate, your non-www not.

www:

CN=hartings.se
	23.10.2019
	21.01.2020
expires in 90 days	hartings.se, www.hartings.se - 2 entries

New and good, with both domain names.

Non-www:

E=root@backupserver-hartings-se, 
CN=backupserver-hartings-se, O=Unspecified, C=US
	15.10.2019
	19.10.2020
expires in 362 days	backupserver-hartings-se - 1 entry

self signed.

There runs an Apache.

What says

apachectl -S
1 Like

Many thanks JuergenAuer for your very quick reply!

This is what I find for

[root@server1 etc]# apachectl -S
VirtualHost configuration:
*:80 hartings.se (/etc/httpd/conf/httpd.conf:478)
*:443 is a NameVirtualHost
default server hartings.se (/etc/httpd/conf.d/ssl.conf:40)
port 443 namevhost hartings.se (/etc/httpd/conf.d/ssl.conf:40)
port 443 namevhost hartings.se (/etc/httpd/conf/httpd-le-ssl.conf:2)
alias www.hartings.se
ServerRoot: “/etc/httpd”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/etc/httpd/logs/error_log”
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default
Mutex cache-socache: using_defaults
Mutex fcgid-pipe: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex fcgid-proctbl: using_defaults
PidFile: “/run/httpd/httpd.pid”
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name=“apache” id=48
Group: name=“apache” id=48
[root@server1 etc]#

Very greatfull for any help to solve this annoying problem!

/Ralf

1 Like

There

you see the problem. Two vHosts with harting.se.

Merge these, check it with

certbot certificates

The result: One vHost with ServerName / ServerAlias and the correct certificate.

Then restart your Apache.

1 Like

Thanks!
OK. I’l look at that immediately.
But do they need to be merged, or should one be deleted (the self-signed one)?
Which one is the self-signed one by the way?

I’ll look at the two files
/etc/httpd/conf.d/ssl.conf:40
/etc/httpd/conf/httpd-le-ssl.conf:2

and let you know what I see…

[root@server1 etc]# more /etc/httpd/conf/httpd-le-ssl.conf

<VirtualHost *:443>
ServerName hartings.se
Redirect / https://hartings.se/
ServerAlias www.hartings.se
RewriteEngine on

Some rewrite rules in this file were disabled on your HTTPS site,

because they have the potential to create redirection loops.

RewriteCond %{SERVER_NAME} =www.hartings.se [OR]

RewriteCond %{SERVER_NAME} =hartings.se

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/hartings.se/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/hartings.se/privkey.pem


[root@server1 etc]#

/etc/httpd/conf.d/ssl.conf is the std config file.
This file includes two lines, which I think refers to the self-signed certificate?:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
By commenting out these two lines, I cannot restart apache…
Don’t know how to merge the files (what to include) and I wonder about a potential problem when the certificates will be renewed lateron in 3 months.

/Ralf

1 Like

Sorry for the font change. Not intended…
Appearently, the “hash” sign caused teh font change. Those line are comments in the file.

1 Like

I want ot make sure that when my certificates are going to be renewed in 3 months, that the same problem will not occur again. Just deleting the two mentioned lines above in the std SSL config file should not cause any problems later, I think. Correct?

I see that my default apache config file includes at the end:

[root@server1 etc]# tail /etc/httpd/conf/httpd.conf
<VirtualHost *:80>
ServerName hartings.se
Redirect / https://hartings.se/
ServerAlias www.hartings.se
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.hartings.se [OR]
RewriteCond %{SERVER_NAME} =hartings.se
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Include /etc/httpd/conf/httpd-le-ssl.conf
[root@server1 etc]#

This points to the right certificate.
Not sure what the :40 and :2 in the file names mean which you wrote:

1 Like

That's your port 80 vHost, that's not relevant to fix your wrong certificate. As written: Merge the two 443 vHosts in one -> merging -> one is to delete.

2 Likes

Hi again,

I copied the two lines from

into the standard config file:

AFTER the section which refers to the self-signed certificates:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
and # systemctl restart httpd
That solved the problem! A "green lock sign" is now again on my website!

Many thanks for pointing me to the right solution!!

2 Likes

That's part of the solution.

But delete now the not used vHost.

Duplicated combinations of port and list of domain names are always bad.

PS: Checked your domain now the main things are ok, Grade B is good.

1 Like

Haven’t deleted the not used vHost yet, but I tested my site at SSL Labs and got grade A!

There are different checks with different results. "check-your-website" -> your domain has a Grade B, missing HSTS. And some minor things you could fix - port 465 + 993 have the wrong certificate. That's not used to calculate the result, but it's good to use public trusted certificates.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.