unable to LETSENCRYPT with ISPCONFIG3.2 on UBUNTUPERFECTSERVER20.04 / possible issue with https

Good Day ahrasis

This where I am at now.

Did a clean install. Made sure the ports where opened. I also kept port forwarding (80) to servers private IP. Also did service apache2 stop since this seemed to help last time. Haven't done anything manually. Just tried running ispconfig_update.sh --force after not getting the cert automatically.

1. First Run: (during fresh install - only port 80 forwarding and required/mentioned opened ports in firewall) it didn't go through. Did check A record properly pointing FQDN with IP (checking done with MXTOOLBOX). In this run, Im configuring remotely with SSH. See below:

Code:

Do you want a secure (SSL) connection to the ISPConfig web interface (y,n) [y]:

Checking / creating certificate for server1.mydomain1.com
Using certificate path /etc/letsencrypt/live/server1.mydomain1.com
Server's public ip(s) ("My Public IP") not found in A/AAAA records for server1.mydomain1.com: "My Private IP"
Ignore DNS check and continue to request certificate? (y,n) [n]:

Could not issue letsencrypt certificate, falling back to self-signed.
Generating a RSA private key
.........++++
.............................................++++
writing new private key to '/usr/local/ispconfig/interface/ssl/ispserver.key'

2. Second Run: Did ispconfig_update.sh --force (remotely with ssh). During this run kept port 80 forwarding and required/mentioned opened ports in firewall with the added scenario of the apache service stoped as mentioned above-. Also did not work. See below:

Code:

Create new ISPConfig SSL certificate (yes,no) [no]: yes

Checking / creating certificate for server1.mydomain1.com
Using certificate path /etc/letsencrypt/live/server1.mydomain1.com
Server's public ip(s) ("My Public IP") not found in A/AAAA records for server1.mydomain1.com: 1"My Private IP"
Ignore DNS check and continue to request certificate? (y,n) [n]: y

Using apache for certificate validation
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for server1.mydomain1.com
Using the webroot path /usr/local/ispconfig/interface/acme for all unmatched domains.
Waiting for verification...
Challenge failed for domain server1.mydomain1.com
http-01 challenge for server1.mydomain1.com
Cleaning up challenges
Some challenges have failed.
Issuing certificate via certbot failed. Please check log files and make sure that your hostname can be verified by letsencrypt
Could not issue letsencrypt certificate, falling back to self-signed.
Generating a RSA private key

3. Went to local terminal at server. With apache2 service On (tried scenarios with port forwarding and without port forwarding). Take note that next result is also coming out now for remote ssh. See below.

Code:

Create new ISPConfig SSL certificate (yes,no) [no]: yes

Checking / creating certificate for server1.mydomain1.com
Using certificate path /etc/letsencrypt/live/server1.mydomain1.com
Server's public ip(s) ("My Public IP") not found in A/AAAA records for server1.mydomain1.com: "My Private IP"
Ignore DNS check and continue to request certificate? (y,n) [n]: y

Using apache for certificate validation
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate
PHP Warning:  symlink(): File exists in /tmp/update_runner.sh.ALwNsuuOBL/install/lib/installer_base.lib.php on line 3135
PHP Warning:  symlink(): File exists in /tmp/update_runner.sh.ALwNsuuOBL/install/lib/installer_base.lib.php on line 3136
Symlink ISPConfig SSL certs to Postfix? (y,n) [y]:

Symlink ISPConfig SSL certs to Pure-FTPd? Creating dhparam file may take some time. (y,n) [y]:


Reconfigure Crontab? (yes,no) [yes]:
Updating Crontab
Restarting services ...
Update finished.

I confess to be getting desperate. By any chance could you give me exact procedures as in what to delete as your prior comment?

Do remind that I haven't installed anything manually. The only thing I have done is trying with APACHE service on and off.

Also take note that letsencrypt is carrying certs at the moment as follows:

/etc/letsencrypt/live/server1.mydomain1.com
cert.pem chain.pem fullchain.pem privkey.pem

/etc/letsencrypt/archive/server1.mydomain1.com
cert1.pem chain1.pem fullchain1.pem privkey1.pem

But the server is still using a self signed cert.

Thank you for the help.

Cheers

 

Follow the LE FAQ and see what's really troubling LE from issuing certs to your server because it is claiming "Server's public ip(s) ("My Public IP") not found in A/AAAA records for server1.mydomain1.com" and fix it properly.

Further, your third step shows weird output "Cert not yet due for renewal" since you never did obtain LE certs for your server as shown in the output for step one and two, so that is why I had advised to remove the LE certs for your server if any exist which is most probably manually created.

 

Just edited my comments above to show the following

Also take note that letsencrypt is carrying certs at the moment as follows:

/etc/letsencrypt/live/server1.mydomain1.com
cert.pem chain.pem fullchain.pem privkey.pem

/etc/letsencrypt/archive/server1.mydomain1.com
cert1.pem chain1.pem fullchain1.pem privkey1.pem

But the server is still using a self signed cert.

Take note as well that when I followed the manual install, it did show Reverse DNS to the HTTP-01 method

 

There was a case which in my mind is quite similar to yours that you might want to read: https://www.howtoforge.com/communit...fy-domain-ssl-cert-could-not-be-issued.87278/ so in short deleting the LE certs and running update again may help and to me is the best.

But as I said before if your problem is only the symlink you can fix it via running ISPConfig update choosing git-stable instead. This however will not fix LE renewal conf that is different from the one issued if you obtained the same using ISPConfig installer.

 

thank you. Will check this right away.
Also I just checked the FAQ

This applies

Haven’t tried this yet thoug

Will comeback with feedback

cheers

 

just checked the recommended url
also Behind NAT as mentioned before

I understand from your post that

In this case for my host, would delete all issued certs in our server?

please advise.

cheers.

 

Because I’m behind NAT, went to the control panel, system, server config, [hostname], SSL and unchecked the “letsencrypt check” as suggested in the FAQ and shared Post

I was also able to delete the cert files as suggested, verified their deletion, and successfully renew the cert, although I still get the two PHP Warnings: symlink(): File exists in /temp/update_runner.sh …. in lines 3135 and 3136 when doing update STABLE (see below)

Question:
when you say force update git-stable, is that the same as stable? I tried doing git-stable but the update only lets me do STABLE NIGHTLY or GIT-DEVELOP

please advise

cheers

 

Sorry about that. It should be nightly now instead of git-stable according to: https://www.ispconfig.org/blog/ispconfig-nightly-builds-available-now/

 

Good Day:
I apologize for not giving feedback sooner. Here is where Im at now.

1. I was able to delete the certs.
2. I was able to eliminate the warnings with nightly update
3. I was able to request new certs.

though

I have opened the Firewall (Port 80 and Port 443).
Do an SSL Checker and get

I can verify with a mail client that the cert is available while trying to authorize a cert name does not match input as follows

I do note that the during update Im not being requested info for the certificate
Also from here I do get a DNS check error.

Code:

Create new ISPConfig SSL certificate (yes,no) [no]: yes

Checking / creating certificate for my.hostname.com
Using certificate path /etc/letsencrypt/live/my.hostname.com
Server's public ip(s) ("My Public IP") not found in A/AAAA records for my.hostname.com: "My Private IP"
Ignore DNS check and continue to request certificate? (y,n) [n]: y

Using apache for certificate validation
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Symlink ISPConfig SSL certs to Postfix? (y,n) [y]:

Symlink ISPConfig SSL certs to Pure-FTPd? Creating dhparam file may take some time. (y,n) [y]:

Reconfigure Crontab? (yes,no) [yes]:

Updating Crontab
Restarting services ...
Update finished.

Do take note that if write on a Browser either my my.hostname.com or "My Public IP", it shows the UBUNTU APACHE MAIN PAGE, proof that por 80 is open
ISPCONFIG on port 8080 with https in front for both my my.hostname.com or "My Public IP" give a message of can't connect because cert is not verified or trusted.

take not as well that although this server is behind NAT, it is the only machine on that subnet.

Please advise

 

Sorry but did you simply check ssl on your hostname.fqdn or your hostname.fqdn:8080 because the certs are by default used in that port only. It also doesn't cover your ip.

 

Ok. Good Observation. I did not proceed as you suggest. I can test check ssl for hostname.fqdn:8080 but first let me just say that I only opened port 8080 in our main Firewall after getting the cert - for further testing -; as I only had port 80 and 443 opened during the cert request. Also take note that this system is private (mail server) and not provided for potential use of third parties different from our own, why I did not see the use of port 8080 available to the outside. I understand from your comment now, that this is mandatory for Letsencryt

So, should I open 8080 instead of 80 for this to work? should I open both?

Code:

Using certificate path /etc/letsencrypt/live/my.hostname.com
Server's public ip(s) ("My Public IP") not found in A/AAAA records for my.hostname.com: "My Private IP"

Please advise

 

Code:

Server's public ip(s) ("My Public IP") not found in A/AAAA records for my.hostname.com: "My Private IP"
Ignore DNS check and continue to request certificate? (y,n) [n]: y

That seems to indicate DNS for your my.hostname.com is not working. That should be fixed before getting certificates. My signature has link to DNS setup tutorial, use the Testing chapter to examine what is wrong with DNS.

 

ISPConfig installer supposedly still should be able to install the certs for any ISPConfig server that do not have web service but I do not think you can check its LE SSL since it will not have a website for it. You also do not have to open any port in that lind of server likse port 80, 443 and 8080 except as needed by its services. The installer will open port 80 and 443 only when it is needed to install or update LE certs will close them back after they were successfully issued.

 

That, at least, I know how to answer
This is the expected behaviour; remember, when Let's Encrypt fails (see the text output you've posted before), ISPConfig will fall back to a self-signed certificate. Aren't the certificates you see under /etc/letsencrypt/live/server1.mydomain1.com self-signed?
You can check them using the following command:

Code:

openssl x509 -in /etc/letsencrypt/live/server1.mydomain1.com/server1.mydomain1.com.cer -noout -text

That extracts the certificate in a readable format (you may wish to pipe it to less); at some point, you should see:

Code:

Issuer: C = US, O = Let's Encrypt, CN = R3

if it's signed by Let's Encrypt. If not, it should show you the data you entered when you created the self-signed certificate, or even say that it's self-signed, or, at worst, mention a 'fake' certificate authority.
If Apache is loading a self-signed certificate from /etc/letsencrypt/live/server1.mydomain1.com, then it's expected that your browser will complain. Also, most browsers should give you an idea of what organisation issued the certificate they don't trust (each does it differently, so the procedure will vary from Firefox to Safari to anything else based on Chromium [including Edge]); you can easily check if it matches with your own certificate or not. In other words: if ISPConfig generated a self-signed certificate, placed it under /etc/letsencrypt/live/server1.mydomain1.com, and Apache is instructed to read the certificates from that very same place (Apache will not complain about self-signed certificates!), then you should be able to confirm that what the browser is getting is the same certificate (the issuers will match).
If that's not the case, then it means that Apache is sending a different certificate to the browser. That's possible; depends on your configuration; also, I'm a nginx fangirl, and not familiar with how ISPConfig handles the Apache configuration. But it's conceivable that some sort of mistake across the long sequence of steps in the procedure might have broken the configuration — and now Apache is serving the first certificate that it has on disk (the 'first' is usually the first virtual host to be loaded!), which may not be the correct one! That would explain quite a lot (and be also a bit harder to track down...).
-----
On a different subject... I understand that you're aware that the cryptic message Server's public ip(s) ("My Public IP") not found in A/AAAA records for server1.mydomain1.com comes simply from the fact that you're using private addressing. From the console/terminal, try the following two commands:

Code:

dig server1.mydomain1.com A (or AAAA)
dig @1.1.1.1 server1.mydomain1.com A (or AAAA)

Do they give you the exact same result? They should — the first request is to your network's nameserver (possibly on your local server), while the second request goes through Cloudflare's own public DNS server (i.e. external to your network).
If they're not the same, then there is an issue with your NAT configuration, and you'll need to address that, since Let's Encrypt really requires a valid, public IP address to process your requests... you have to make sure that this is the case, always! Opening ports in the firewall (i presume that you mean the Linux firewall, configured via ISPConfig...?) will be worthless unless NAT is correctly configured from the very beginning!