Trouble dealing with hostname and SSL certs

SYSTEM INFORMATION
OS type and version Rocky Linux 8.10
Usermin version 2.102
Virtualmin version 7.20.2 Pro
Theme version 21.20.7
Apache version 2.4.37
Package updates All installed packages are up to date

I have mydomain.tld
I use various hostnames across multiple servers. For instance, host1.mydomain.tld.
I also still have active some alternate mailserver names for these systems, such as mail2.mydomain.tld, mail3.mydomain.tld, etc. This was done some years back due to Apple suddenly requiring secure connections before LetsEncrypt had become widely. I had been using a wildcard Sectigo cert across all systems but didn’t see the need to keep paying for that.

I’ve been fighting this since the change to Virtualmin with the 7.2 release.

Other info. I use the hostname in $mydestination of Postfix.

What is now the preferred method for such a setup?

I have one subdomain at the moment which can’t send email due to a LetsEncrypt SSL error.

I’m not sure to understand the question. Did you requested a Let’s Encrypt ssl certificate through virtualmin.

Go in: Server Configuration > SSL Certificate > Let’s Encrypt > Request certificate for > Domain names listed here

If yes, in the domain listed here, did you listed each domain/subdomain which need it ?

Sorry if I said a mistake (please correct me if I’m wrong) but I remember we can not ask a wild card certificate to LetsEncrypt (at least not this way). But we have to list each subdomain.

If you did it. Can you share the link to your site or show us the error you are getting ?

At the moment, on one system, LetsEncrypt is now failing on any request.

The Error:
An unexpected error occurred:
requests.exceptions.SSLError: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)’),))
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

This is a rather. Seaching and searching I find a good many reports with very widespread solutions. Looking at each I have found, none provide my resolve.

I am suspecting it could be the lack of a cert for hostname.mydomain.tld for the server. It seems that any way I try to create it, through Webmin config or otherwise, I don’t succeed.

I would look there for the error

Would be nice to have the list of domain you try to get a certificate for, AND also DNS entries at your domain name provider.

There are not enough clues to give a solution. And obviously the log as @jimr1 said.

Here is the letsencrypt.log

2024-10-09 13:19:32,284:DEBUG:certbot._internal.main:certbot version: 1.22.0
2024-10-09 13:19:32,285:DEBUG:certbot._internal.main:Location of certbot entry point: /bin/letsencrypt
2024-10-09 13:19:32,285:DEBUG:certbot._internal.main:Arguments: [‘-a’, ‘webroot’, ‘-d’, ‘webmail.preflooring.com’, ‘-d’, ‘mail.preflooring.com’, ‘-d’, ‘autoconfig.preflooring.com’, ‘-d’, ‘autodiscover.preflooring.com’, ‘–webroot-path’, ‘/home/preflooring/public_html’, ‘–duplicate’, ‘–force-renewal’, ‘–non-interactive’, ‘–agree-tos’, ‘–config’, ‘/tmp/.webmin/933008_3176651_4_collectinfo.pl’, ‘–rsa-key-size’, ‘2048’, ‘–cert-name’, ‘webmail.preflooring.com’, ‘–reuse-key’]
2024-10-09 13:19:32,286:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-10-09 13:19:32,336:DEBUG:certbot._internal.log:Root logging level set at 30
2024-10-09 13:19:32,338:DEBUG:certbot._internal.plugins.selection:Requested authenticator webroot and installer None
2024-10-09 13:19:32,342:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: Authenticator, Plugin
Entry point: webroot = certbot._internal.plugins.webroot:Authenticator
Initialized: <certbot._internal.plugins.webroot.Authenticator object at 0x7fc422f7ed68>
Prep: True
2024-10-09 13:19:32,343:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot._internal.plugins.webroot.Authenticator object at 0x7fc422f7ed68> and installer None
2024-10-09 13:19:32,343:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator webroot, Installer None
2024-10-09 13:19:32,358:DEBUG:certbot._internal.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=(), agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri=‘https://acme-v02.api.letsencrypt.org/acme/acct/96937123’, new_authzr_uri=None, terms_of_service=None), 3fcd6fbbb302cd9297c891639737c80d, Meta(creation_dt=datetime.datetime(2020, 9, 17, 21, 49, 31, tzinfo=), creation_host=‘mars.ew3d.com’, register_to_eff=None))>
2024-10-09 13:19:32,359:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2024-10-09 13:19:32,361:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org:443
2024-10-09 13:19:32,479:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 601, in urlopen
chunked=chunked)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 344, in _make_request
self._validate_conn(conn)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 844, in validate_conn
conn.connect()
File “/usr/lib/python3.6/site-packages/urllib3/connection.py”, line 358, in connect
ssl_context=context)
File "/usr/lib/python3.6/site-packages/urllib3/util/ssl
.py", line 354, in ssl_wrap_socket
return context.wrap_socket(sock, server_hostname=server_hostname)
File “/usr/lib64/python3.6/ssl.py”, line 365, in wrap_socket
_context=self, _session=session)
File “/usr/lib64/python3.6/ssl.py”, line 810, in init
self.do_handshake()
File “/usr/lib64/python3.6/ssl.py”, line 1070, in do_handshake
self._sslobj.do_handshake()
File “/usr/lib64/python3.6/ssl.py”, line 648, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/requests/adapters.py”, line 449, in send
timeout=timeout
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 639, in urlopen
_stacktrace=sys.exc_info()[2])
File “/usr/lib/python3.6/site-packages/urllib3/util/retry.py”, line 399, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)’),))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/bin/letsencrypt”, line 11, in
load_entry_point(‘certbot==1.22.0’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python3.6/site-packages/certbot/main.py”, line 19, in main
return internal_main.main(cli_args)
File “/usr/lib/python3.6/site-packages/certbot/_internal/main.py”, line 1632, in main
return config.func(config, plugins)
File “/usr/lib/python3.6/site-packages/certbot/_internal/main.py”, line 1473, in certonly
le_client = _init_le_client(config, auth, installer)
File “/usr/lib/python3.6/site-packages/certbot/_internal/main.py”, line 793, in _init_le_client
return client.Client(config, acc, authenticator, installer, acme=acme)
File “/usr/lib/python3.6/site-packages/certbot/_internal/client.py”, line 294, in init
acme = acme_from_config_key(config, self.account.key, self.account.regr)
File “/usr/lib/python3.6/site-packages/certbot/_internal/client.py”, line 59, in acme_from_config_key
client = acme_client.BackwardsCompatibleClientV2(net, key, config.server)
File “/usr/lib/python3.6/site-packages/acme/client.py”, line 875, in init
directory = messages.Directory.from_json(net.get(server).json())
File “/usr/lib/python3.6/site-packages/acme/client.py”, line 1236, in get
self._send_request(‘GET’, url, **kwargs), content_type=content_type)
File “/usr/lib/python3.6/site-packages/acme/client.py”, line 1174, in _send_request
response = self.session.request(method, url, *args, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 535, in request
resp = self.send(prep, **send_kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 648, in send
r = adapter.send(request, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/adapters.py”, line 514, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)’),))
2024-10-09 13:19:32,482:ERROR:certbot._internal.log:An unexpected error occurred:
2024-10-09 13:19:32,483:ERROR:certbot._internal.log:requests.exceptions.SSLError: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)’),))

I run my own nameservers. They are functioning properly.

What I cannot do is create a cert for mars.ew3d.com which is the hostname for this system. Each way I try is blocked by Virtualmin/Webmin. I had in the past been using Virtualmin which had an entry for mars.ew3d.com. I was trying to fix this to conform to Virtualmin 7.2 when I hit this issue.

I have tried each of the options in the Webmin config SSL area and none function. At the moment, I have it pointed to one of the mailserver alternative certs, or mail3.ew3d.com which does not have mars.ew3d.com included within that cert.

I think this issue is due to no cert for mars.ew3d.com. But I can’t find a method within Virtualmin nor Webmin to create one.

It is never that. Or, it never needs to be that. You never need to connect to the hostname of your system for any purpose. You can use one of your Virtualmin domains for everything. Pretend like the system hostname doesn’t even exist.

Outgoing connections may include the system hostname, but that doesn’t matter because outgoing doesn’t need a certificate (the server Postfix is connecting to is the one that needs a cert). Everything your clients interact with can be a Virtualmin domain name, and it is very easy to get certs for Virtualmin domains.

1 Like

IIRC after a new Webmin/Virtualmin install, the link given to access it is https://hostname.domain.tld:10000? Am I remembering wrong or has this changed? I guess I’ll need to create something like hostnamewebmin.domain.tld to access the systems directly via a suedoname? Why is adding hostname.domain.tld as a Virtual host? I do see it can cause oddities with sni maps and such. But I couldn’t even add it as a subdomain under domain.tld. Just curious if this is a Linux limitation or a Webmin/Virtualmin limitation.

Meanwhile, the above letsencrypt log was from a domain on that system. I get the same error on any domain when trying to renew a cert on this system.

So the “Max retries exceeded” is to reach acme-v02.api.letsencrypt.org/directory if I correctly understood.

The “Exiting abnormally” which follow, Isn’t it simply LetsEncrypt which close the connection ?

So the “max retries exceeded” would be your server/virtualmin which try to reconnect over and over because the previous connection have been aborted

Sorry If I misunderstand.

Then you said “I run my own nameservers”.

Is it behind a domestic/home/residential router ?

Sorry to insist on this point but it might simply be let’s encrypt which doesn’t see it (Due to a router update) but I don’t think it would throw this error (If I remember, but I’m not sure).

If it work for mail3.ew3d.com, ew3d.com and www.ew3d.com. If your own nameservers is correctly setup for mars.ew3d.com it shall work too.

Then could the subdomain name itself “mars” have done something wrong in the past (at least according to let’s encrypt). Especially if it sent usually a lot of mail.

I’m suggesting but I’m far to be sure

So on an other server/IP it works ?

This is a public network serving many business websites and email accounts. I run around 10 different systems and have been doing this since the late 90’s. This particular system is email only for various domains and is a slave nameserver. DNS is not turned on as a feature in Virtualmin as this is not the main nameserver. I just needed another slave. This has all worked up until:
a) I did not renew and quit using a Sectigo Wildcard cert.
b) Started using LetsEncrypt for all certs
c) The removal of mars.ew3d.com from Virtualmin virtual servers and tried to recreate it after Virtualmin 7.2

I have not yet started going this far with my other systems until I find out what has happened to this system.

That’s just to get rid of the certificate warning that is inevitable if we don’t try to get a cert for the hostname. You don’t have any Virtualmin domains immediately after installation. Once you create a domain, you do…at which point you have no reason to ever need to use the system hostname for anything ever again. If you’re trying to use the system hostname for anything, you’re just making your life harder for no reason.

1 Like

I need to get onto actually fixing the issue. No domains will renew on this system at the moment.

  1. Does Virtualmin have any configurations created within itself with regards to Certbot? Or does Virtualmin simply provide an interface to Certbot (LetsEncrypt)?
  2. If Virtualmin does not store any info, what is my best path to rectifying the problem? Uninstall and reinstall Certbot? Perhaps replace files on this system with files from a working system?

Thanks!

I’ve done the honors for you and deleted all my post @Joe

Thanks for the suggestions.

Virtualmin will not let you do #2. It prevents that as well. I’m going to conform to what Virtualmin is doing on hostnames. I’ll just create something like hostname2.domain.tld for use alongside of hostname.

When searching this issue via Google. Mention was made that if it hostname did not have a cert, that would cause this failure. But, I can’t find that now and don’t know if it is true or just bad advice. This error is so ‘generalized’ it’s tough to figure out the problem from the logs. I did find the hostname in one of the Certbot config files.

I’m hoping to find out another way to fix this aside from a total server rebuild. It’s really hard to fix something on a live server with hundreds of email accounts across a lot of domain names. No room for a serious misstep.

No. The system hostname is unrelated to certificates for Virtualmin domains.

It’s not true. I’ve told you the system hostname is unrelated to Virtualmin domain certificates and Let’s Encrypt. If you don’t trust me, I don’t know who you’d believe.

Anyway, I can’t think through so many unrelated things. Please just forget about the system hostname for now. If you still want to do something with the system hostname, despite my recommendation to forget it exists, make a new topic for those questions. It absolutely has nothing to do with certificates for Virtualmin domains.

Let’s focus on fixing the Virtualmin domains, so this crazy long thread can end. That is a simple problem. It has known solutions, well-understood problems that can prevent validation from working.

The problems are always one of the following:

  1. DNS. Do you have records for all of the names you’re trying to request a certificate for and do they all point to the right IP? Make sure you are not requesting certificates for names that do not have records. If you’re requesting a cert for the automatically generated alias names like admin.domain.tld cert, you need an A record for it, or you need to disable those automatic aliases when requesting the certificate. You cannot request a cert for a name that does not exist.
  2. Something is sucking up the request before it reaches the filesystem where the validation file is generated. If you have proxy rules or redirect rules for an application, anything happening in .htaccess, it needs to exclude the .well-known directory. Test this: Put a file in /home/domain/public_html/.well-known and request that file with your browser. If you can’t reach it, you must fix that.

Some things you can do to make your life easier:

  1. Disable features you aren’t using. If you aren’t managing DNS locally with Virtualmin, don’t let Virtualmin believe you are. Likewise, if you don’t use the admin or webmail redirects, disable them.
  2. Simplify the problem you’re trying to solve to one variable. This thread is all over the place, and I can’t keep up. I can tell you how to solve a problem with Virtualmin domains not being able to validate with Let’s Encrypt. We have hundreds of threads about that here, and they all got solved, because they were all the same two or three problems. If you focus, we can solve the problem easily.
1 Like

I apologize for the abuse of this thread due to the title. I’m starting a new thread.

I’ve done the honors for you and deleted all my post @Joe

I’ve done the honors for you and deleted all my post @Joe

But as @Joe said you don’t ask certificate for hostname. It’s unrelated with https connection. The hostname doesn’t matter for ssl certificate. Only the A record does and then it’s the server which take care of redirections.

(Or I’m missing something, due to the fact I’m not english And I missunderstood/messed up with the whole )

If you want a certificate for mars.ew3d.com You directly ask a certificate for it. And not for the redirection to it. You don’t ask a certificate for “mail3.ew3d.com” to then get a certificate for a redirection to mars.ew3d.com.
What we do is asking a certificate for both “mail3.ew3d.com” and “mars.ew3d.com”. Everything concerning redirection and hostname is unrelated. It’s the server which handle this; Not let’s encrypt.

(Or again I’m missing something with english And I missunderstood/messed up with the whole )