[SOLVED] Certbot - Confusion About How To Deal with A Certificate Which Doesn't Cover the Right Domain Names

Help
1

The incorrect certificate was granted 10 ten days ago and I thought it would be released after about a week.

Also I am surprised and curious to know why an incorrect certificate is saved unlike compilers that do not save an executable if there are errors in the scripts.

I have tried without success to delete and revoke and also followed and tried numerous topics with similar problems.

“Johns-Jokes.com” is the problematic URL shared on a DigitalOcean VPS that has three other valid SSH certificates and a few other URLs that are not encrypted.

Should I wait just a little bit longer or will the incorrect certificate remain forever?

2

I’m not sure what’s going on here. Let’s Encrypt doesn’t “hold” incorrect certificates. I really don’t understand what you mean exactly.

Perhaps you could fill in the following questions?

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:

It produced this output:

My operating system is (include version):

My web server is (include version):

My hosting provider, if applicable, is:

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

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

1 Like
3

Many thanks @Osiris for your prompt reply.

Osiris Osiris
May 10

I'm not sure what's going on here.
Let's Encrypt doesn't "hold" incorrect certificates.
I really don't understand what you mean exactly.
Why does my .htaccess file have no effect?

There is no Cloud Hosting involved so why does .htaccess have no effect.


My domain is:

johns-jokes.com
www.johns-jokes.com
subs.johns-jokes.com

I ran this command:

# sudo certbot revoke 
-d johns-jokes.com  
--cert-path /etc/letsencrypt/live/johns-jokes.com/fullchain.pem 
--key-path  /etc/letsencrypt/live/www.supiet2.tk/privkey.pem

It produced this output:

usage: 
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates.  
By default, it will attempt to use a webserver both 
for obtaining and installing the cert. 
certbot: error: argument --cert-path: No such file or directory

My operating system is (include version):

# sudo php -v
PHP 7.0.18-1+deb.sury.org~xenial+1 (cli) (built: Apr 11 2017 14:36:44) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.18-1+deb.sury.org~xenial+1, 
Copyright (c) 1999-2017, by Zend Technologies

My web server is (include version):

# sudo apache2 -version
Server version: Apache/2.4.18 (Ubuntu)
Server built:   2017-05-05T16:32:00

My hosting provider, if applicable, is:

https://www.aisn.net/
https://www.digitalocean.com/

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

Yes and can use ssh and DigitalOcean's Online Services
John-Betong 1 GB / 20 GB Disk / SFO1 - Ubuntu John-Betong 2016-03-18
104.236.188.234 Copy	2 years ago
disk usage about 50% of 20 GB

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

No

I hope this is sufficient information to resolve the problem.

4

Well it said right there that you are using the incorrect syntax for the command.

1 Like
5

@EnumC

I read in one of the topics that the -cert-path and -key-path could be removed.

I just replaced the removed files and this is the new command and result:

sudo certbot revoke
-d johns-jokes.com
--cert-path /etc/letsencrypt/live/www.johns-jokes.com/fullchain.pem
--key-path /etc/letsencrypt/live/www.johns-jokes.com/privkey.pem
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Congratulations! You have successfully revoked the certificate 
that was located at /etc/letsencrypt/live/www.johns-jokes.com/fullchain.pem

TESTING

https://www.ssllabs.com/ssltest/analyze.html?d=johns-jokes.com?=johns-joes.com

Even after clearing the cache the following error is still reported:
"Certificate name mismatch"

How long does it take to clear the https://ssllabs.com's cache?

6

Your domain and private key can be omitted, but you have to be pointing to your certificate that you want to revoke. Are you sure you are revoking the correct cert as the one you currently have deployed? The one your website is serving have a common name for anetizer.com, which is showing up as not revoked.
https://crt.sh/?q=a345597760b05f346dd3eb279064784a15ec841c002979e4b8138a6ca92f8e15

1 Like
7

Why are you revoking anything? Your problem is that you are using a certificate that doesn’t have your hostname on it. Generate a cert for the three hostnames you do want, and configure Apache to use that cert. If you want that cert to also cover the three hostnames that you’re currently covering, then all six names need to be on the cert. Nothing needs to be revoked.

6 Likes
8

hi @John_Betong

This topic is really unorganised which is where a lot of the confusion is coming from.

The incorrect certificate was granted 10 ten days ago and I thought it would be released after about a week.

Certbot has no way of determining what a correct or incorrect certificate is. You specify the domain names you want to be covered by your certificate and as long as the challenges are passable certbot will issue you a certificate.

Whether that certificate is correct for what you are trying to do is a USER (you) related issue. It's a computer and it will do what it tells you to do or what someone has programmed it to do.

I have tried without success to delete and revoke and also followed and tried numerous topics with similar problems.

There are two issues at stake here. A review of the manual would have cleared this up.

https://certbot.eff.org/docs/using.html

image.png737×221 12.2 KB

Managing certificates with certbot

Revoking is something you do publicly. Deleting a certificate is something you do within certbot.

"Johns-Jokes.com" is the problematic URL shared on a DigitalOcean VPS that has three other valid SSH certificates and a few other URLs that are not encrypted

SSH uses keys not certificates. Certificates are a TLS concept not a SSH Concept.

Should I wait just a little bit longer or will the incorrect certificate remain forever?

Once again a gentle review of the manual would have told you that certificates are valid for 90 days.

image.png1021×144 12.8 KB

My general feeling is that this should have been an approach question.

I tried x however it's not in line with what I was hoping how would I go about it.

Some prep work goes a long way as well.

Generally if you issue a certificate that is not in line with what you want letting it expire is a fine approach.

Andrei

1 Like
9

It’s important to understand that the web public key infrastructure, and the Let’s Encrypt CA, allow overlapping certificates that are valid for the same domain name at the same time. There can be an unlimited number of certificates that are all valid for the same name at the same time (although Let’s Encrypt has some limits on the number of new certificates you can request per week that cover the same name).

There are no technologies in mainstream browsers that directly say “this certificate isn’t valid because there’s another ‘contrary’ certificate that I know about”. Instead, the server serves a particular certificate on each connection, and the browser evaluates that certificate to see if it agrees that it’s valid at the moment for the domain name that the browser connected to.

Therefore, @danb35 is right that if the browser (or SSL Labs) is receiving a certificate that doesn’t match the domain name, it’s not necessary to destroy or revoke old certificates in order to fix the problem; instead, it’s necessary to fix the web server configuration to make sure that the web server is willing to serve a certificate that is valid. (And, of course, you also have to obtain such a certificate if you don’t already have one.)

There is a technology called HPKP where you can specify that browsers should refuse to accept certificates for your site in the future if they don’t match certain criteria, but you have to explicitly choose to use that technology, and both the browser and SSL Labs would say so if that were the reason that a certificate were rejected (rather than due to a simple name mismatch).

2 Likes
10

I can also see that compared to your CloudFlare SSL certificate the LetsEncrypt Certificate you issued is very different

https://crt.sh/?q=Johns-Jokes.com

LetsEncrypt based certificate:

X509v3 Subject Alternative Name:
DNS:johns-jokes.com
DNS:subs.johns-jokes.com
DNS:www.johns-jokes.com

CloudFlare Certificate:

        X509v3 Subject Alternative Name: 
            DNS:sni253593.cloudflaressl.com
            DNS:*.2tfrag.com
            DNS:*.7ux61k3.gq
            DNS:*.bezerros.info
            DNS:*.catsayk.cf
            DNS:*.famousexpress.xyz
            DNS:*.gettmagnet.gq
            DNS:*.herekfilepy.cf
            DNS:*.jgly.info
            DNS:*.johns-jokes.com
            DNS:*.livingbookslibrary.cf
            DNS:*.meaningsurnamebaker.xyz
            DNS:*.metrmyown.tk
            DNS:*.panbit.xyz
            DNS:*.price-take.xyz
            DNS:*.quantbeat.com
            DNS:*.rowpawe.cf
            DNS:*.trialfavor.xyz
            DNS:*.udszcz.gq
            DNS:*.watertestinglocalexperts.com
            DNS:*.whatdoesthelastnamealdrichmean.xyz
            DNS:2tfrag.com
            DNS:7ux61k3.gq
            DNS:bezerros.info
            DNS:catsayk.cf
            DNS:famousexpress.xyz
            DNS:gettmagnet.gq
            DNS:herekfilepy.cf
            DNS:jgly.info
            DNS:johns-jokes.com
            DNS:livingbookslibrary.cf
            DNS:meaningsurnamebaker.xyz
            DNS:metrmyown.tk
            DNS:panbit.xyz
            DNS:price-take.xyz
            DNS:quantbeat.com
            DNS:rowpawe.cf
            DNS:trialfavor.xyz
            DNS:udszcz.gq
            DNS:watertestinglocalexperts.com
            DNS:whatdoesthelastnamealdrichmean.xyz

Andrei

1 Like
11

once again as long as you want

image.png1280×598 40.3 KB

1 Like
12

The difference in SAN hostnames is because CloudFlare accumulates many different hostnames into one single certificate. Those hostnames do not have to be related.

1 Like
13

Many thanks for all the replies.

At the moment CloudFlare is not active, would it be better to reactive before trying for a new certificate or to try activating CloudFlare afterwards.

I do not mind if CloudFlare is not activated because many web pages are AmpProject.org compatible.

Later when I am on the desktop I will try for a new certificate.

14

Depends on which challenge you used to issue/install the certificate.

If you used the apache plugin, it will not work with CloudFlare. However, the webroot plugin will work like a charm.

1 Like
15

I still have not activated CloudFlare and tried the following:

sudo certbot certonly --webroot -w /var/www/johns-jokes.com -d johns-jokes.com -d www.johns-jokes.com -d subs.johns-jokes.com -d anetizer.com -d www.anetizer.com -d subs.anetizer.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/johns-jokes.com.conf)

It contains these names: johns-jokes.com, subs.johns-jokes.com,
www.johns-jokes.com

You requested these names for the new certificate: johns-jokes.com,
www.johns-jokes.com, subs.johns-jokes.com, anetizer.com, www.anetizer.com,
subs.anetizer.com.

Do you want to expand and replace this existing certificate with the new
certificate?

(E)xpand/(C)ancel: e
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for johns-jokes.com
http-01 challenge for www.johns-jokes.com
http-01 challenge for subs.johns-jokes.com
http-01 challenge for anetizer.com
http-01 challenge for www.anetizer.com
http-01 challenge for subs.anetizer.com
Using the webroot path /var/www/johns-jokes.com for all unmatched domains.
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
UnicodeEncodeError: 'ascii' codec can't encode character u'\u26a1' in position 217: ordinal not in range(128)
Please see the logfiles in /var/log/letsencrypt for more details.
root@John-Betong:~# sudo certbot certonly --webroot -w /var/www/johns-jokes.com -d johns-jokes.com -d www.johns-jokes.com -d subs.johns-jokes.com -d anetizer.com -d www.anetizer.com -d subs.anetizer.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log


### Log file > 2017-05-11 10:11:36,003:DEBUG:certbot.plugins.webroot:All challenges cleaned up, removing /var/www/johns-jokes.com/.well-known/acme-challenge 2017-05-11 10:11:36,005:DEBUG:certbot.main:Exiting abnormally: Traceback (most recent call last): File "/usr/bin/certbot", line 11, in load_entry_point('certbot==0.12.0', 'console_scripts', 'certbot')() File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 896, in main return config.func(config, plugins) File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 692, in certonly lineage = _get_and_save_cert(le_client, config, domains, certname, lineage) File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 87, in _get_and_save_cert renewal.renew_cert(config, domains, le_client, lineage) File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 296, in renew_cert new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains) File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 265, in obtain_certificate self.config.allow_subset_of_names) File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 77, in get_authorizations self._respond(resp, best_effort) File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 134, in _respond self._poll_challenges(chall_update, best_effort) File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 197, in _poll_challenges _report_failed_challs(all_failed_achalls) File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 488, in _report_failed_challs _generate_failed_chall_msg(achalls), reporter.MEDIUM_PRIORITY) File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 504, in _generate_failed_chall_msg if messages.is_acme_error(error): File "/usr/lib/python2.7/dist-packages/acme/messages.py", line 39, in is_acme_error return (ERROR_PREFIX in str(err)) or (OLD_ERROR_PREFIX in str(err)) UnicodeEncodeError: 'ascii' codec can't encode character u'\u26a1' in position 217: ordinal not in range(128)
16

Does any of your site names or even the content of your site contain the lightning bolt character :zap:, especially as part of a 404 not found error? That is the character u’\u26a1’ complained of here.

If so, I think this might be a known bug (which in turn happens when you specify the incorrect webroot directory and the content returned by the server contains non-ASCII characters).

1 Like
17

Unfortunately the forum software rendered the character in question with an emoji, but it is the character that can be seen further down on this page: http://www.fileformat.info/info/unicode/char/26a1/index.htm

1 Like
18

Yes the emoji is present because the web page did have the following the AmpProjct.org header. It was later revised because the html amp reference now triggers AMP validation warnings. The latest recommendation is to replace amp with the lightning emoji.

<!doctype html>
<html amp lang="en">

Yesterday, I edited the common CodeIgniter index.php file with a <?php exit(); but it looks as though this was ignored and the file was parsed.

Also with CodeIgniter the recommended.htaccess 404 setting is index.php which gracefully handles all errors.

Many thanks again for your patience and astute observations.

Later this morning, I look forward to removing the emoji and to again try installing the Certbot certificate.

The Anetizer.com site is working ok, also uses CodeIgniter and AmpProject specifications. When I am on the desktop I will check the index.php header and report back.

19

Sorry I didn’t give more context. It’s not a problem to have emoji or Unicode text on your web site. However, this particular bug arises in a case when HTTP-01 validation with --webroot failed and then the CA quoted the 404 page (that contained Unicode). The Unicode did not cause the validation to fail; instead, it caused Certbot to fail to explain properly that the validation failed.

Removing the Unicode character from your page will not make the problem go away. Instead, you’d see a message from the CA explaining that HTTP-01 validation failed, which is normally because you specified the wrong webroot directory with -w, for example specifying a webroot that applied to a different site rather than the site you were trying to get the certificate for. For each site that you mention with -d, you should provide an additional -w option (prior to the -d) giving the appropriate webroot for that site.

What I think happened is that you only specified a single webroot, /var/www/johns-jokes.com, but you requested certificates for what are probably at least four different sites in terms of their contents, without specifying the respective webroots for the additional 3 sites. That in turn caused a 404 error, which could not be correctly displayed to you by Certbot because of the presence of the Unicode character in the error message text.

1 Like
20

I tried numerous times, failed and now exceeded the limit.

Error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently.

Is it possible to start all over again without any sub-domains?