Wrong subjectAlternativeName with certbot dns-01 challenge


#1

My domain is: calculator.360-biz.com
My web server is (include version): Apache HTTPD 2.4.66-8
The operating system my web server runs on is (include version): RHEL 7.6
I can login to a root shell on my machine (yes or no, or I don’t know): yes

I ran this command:
sudo certbot certonly --manual --preferred-challenges dns-01 -d calculator.360-biz.com
and successfully obtained a cert, but once set up in my Apache server, Chrome reports an incorrect subjectAlternativeName, which is true. The certificate was issued for the root domain (360-biz.com), and not the subdomain.

I’m managing the DNS with GoDaddy and I suppose the error might be here. In order for the challenge to work, I had to shorten the TXT values to “_acme-challenge.calculator” and <certbot_value> instead of the full domain, otherwise it was failing.

This wouldn’t be painful except that the http-01 challenge is also not working. Any ideas?


#2

Hi @MCDELTAT

if you use -d calculator.360-biz.com, you create one certificate with this one domain name. So the certificate was issued for the subdomain.

Installed is another certificate:

CN=360-biz.com
	08.01.2019
	08.04.2019
	360-biz.com, 360businessconsulting.com, 
360civic.com, www.360-biz.com, www.360businessconsulting.com, 
www.360civic.com - 6 entries

This is correct.

The complete name must be

_acme-challenge.calculator.360-biz.com

but the menu adds the domain name. So it’s not the wrong name

_acme-challenge.calculator.360-biz.com.calculator.360-biz.com

with a double domain name.


#3

Note the CERTONLY in the command.

Please show:
sudo certbot certificates

According to this a cert was issued:
https://crt.sh/?q=calculator.360-biz.com


#4

@rg305 @JuergenAuer
The output of sudo certbot certificates shows several of my other certificates, but for this issue it is:

Certificate Name: calculator.360-biz.com
Domains: calculator.360-biz.com
Expiry Date: 2019-04-08 20:31:25+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/calculator.360-biz.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/calculator.360-biz.com/privkey.pem

I manually created the entry in /etc/httpd/conf/httpd-le-ssl.conf as follows:

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName calculator.360-biz.com
DocumentRoot /var/www/html/calculator
DirectoryIndex index.php
CustomLog logs/calc-access_log common
ErrorLog logs/calc-error_log
<Directory "/var/www/html/calculator">
AllowOverride All
Require all granted
Options -Indexes
</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/calculator.360-biz.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/calculator.360-biz.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/calculator.360-biz.com/chain.pem
</VirtualHost>
</IfModule>

So it would appear that I am indeed using the correct certificate. Is there something that could be caching this bad cert? I restarted httpd just in case.


#5

https://www.ssllabs.com/ssltest/analyze.html?d=calculator.360-biz.com

The restart was probably the missing piece.
Again using CERTONLY doesn’t do much of what you had to do manually.


#6

Ah. I spotted my error. Certbot always generates the virtual host as

<VirtualHost 172.24.16.158:443>

whereas I was using the wildcard *. Is this always the case?

My site is fine now from Chrome. Hopefully I’ll be able to renew with the tls-sni-01 challenge later, otherwise I’ll be stuck renewing manually. Can I test the renewal mechanism even when not near expiration?


#7

Yes, use:
--dry-run


#8

This doesn’t seem right - when using CERTONLY it doesn’t make any such changes.


#9

All the others were created using the automatic http-01 challenge. This site in particular has some issue with that challenge, so I couldn’t.

Will TLS-01 challenge now.


#10

Certbot doesn’t always use one or the other - it uses whichever it thinks you’re already using.

I remember there used to be a bug where it could guess wrong if you had a mix of *'s and IP addresses, and I don’t know if that’s been fixed yet. Do you have something like that in your Apache config?

You won’t. The TLS-SNI-01 challenge is being removed soon (it’s been deprecated for some time because of a security issue).


#11

Tls-sni-01 is dead - 2019-02-13