Let's encrypt on LAMP under UBUNTU 16.04

Hello, and Happy new year everybody !

I try to install a ssl on my LAMP (UBUNTU 16.04) for my local “noticedevote.dev” wich is install on APACHE2 through a virtualhost containing “servername noticedevote.dev”, according to this DIY manual : https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04.

BUT, on the fourth step : sudo certbot --apache -d noticedevote.dev
I got this reply :

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for noticedevote.dev
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. noticedevote.dev (tls-sni-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No valid IP addresses found for noticedevote.dev


  • The following errors were reported by the server:

    Domain: noticedevote.dev
    Type: unknownHost
    Detail: No valid IP addresses found for noticedevote.dev

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

Could you please show me the way to fix this point ?

Looking forward to your reply, I thank you per advance.
Best regards,

Your “local” FQDN resolves to a non-public IP address:

noticedevote.dev.	3600	IN	A

With the apache plugin, you’re automatically using the tls-sni-01 challenge to verify the ownership of your FQDN, which tries to connect to the resolved IP address.

Logically, because the resolved IP address is not a public accessible IP address, Let’s Encrypt can’t connect to it, so it refuses to follow through with the validation process.

When using a publically available FQDN with a non-publically available IP address, you’re only choice to validate the ownership of the FQDN is using the dns-01 challenge.

The official certbot plugin using the dns challenge is the manual plugin.
You can use the apache plugin for installing the certificate and the manual plugin for the authentication/validation with the dns plugin as follows:

sudo certbot -i apache -a manual --preferred-challenges dns -d noticedevote.dev

Unfortunately, for the manual plugin to be automated, you’ll have to use scripts for the interaction with your DNS server: https://certbot.eff.org/docs/using.html#manual

If you don’t care about automation (note: Let’s Encrypt certificates are only valid for 90 days), you can just manually follow the instructions presented to you by certbot, no scripting required, just manually renewing the certificates every 90 days.

If you check the [certbot Github repository](https://github.com/certbot/certbot) however, you can see many DNS provider plugins available. I have NO clue at all on how to install those plugins and perhaps your DNS provider isn't among the providers with a plugin available. If so, your only method is themanual` plugin as mentioned above.

I believe that @RolandG didn’t actually register noticedevote.dev.

@RolandG, Let’s Encrypt certificates not intended for use with internal (non-publicly-registered domain names). Our certificates are asserting to the public that the certificate holder actually controls the domain name mentioned in the certificate (on the public Internet as a whole). If you don’t, you can’t prove to Let’s Encrypt that you do, and Let’s Encrypt can’t issue you a certificate for this name to assert to third parties that you do.

In this case, you should use a self-signed certificate instead.

Hi Schoen,

Thank you very much for your detailled reply.
I’ll use a self-signed certificate, the purpose of this particular
configuration is only developpement.

Have a sweet day.
Best regards,

Hi @RolandG,

This is off topic but just in case you don't know it... the .dev gTLD is not a "fake" gTLD, it is real and is owned by Google. You can't register a .dev domain yet but maybe you could in a future so you could have issues if another user registers your fake/internal dev domain. Also, .dev domains are included in HSTS preload list, at least in Chrome, which means that Chrome will try to connect to your domain, always, in a secure way (using https) and you could also have some issues... so I suppose it should be better to choose another fake TLD instead of dev ;).

This article explains the issue better than me :wink:


Hi Shasanu,

I just read your mail. That’s very kind of you to explain me this point.
Actually, my “noticedevote.dev” website is only for local development
purpose on my lamp, whith no external access.
The real website will be “noticedevote.online” wich I yet bought.

Anyway, thank you very much four your involvement

best regards,

1 Like

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