How to get Let's Encrypt certificates for internal servers

hmm, it is like you wrote:
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

Sorry, I did not recognize your empty localhost.key…

I moved my key and fired certificate-update event and localhost.key is recreated.

mv /etc/pki/tls/private/localhost.key ~
signal-event certificate-update

Maybe you have to set the db props you changed to default values again.

My values with letsencrypt cert:

# config show pki
1 Like

i dont get it, maybe i am too dumb. if i look at config show pki i got


formerly, i guess, it was like your configuration cause i have exact this kind of folders from letsencrypt.
is there a file to edit for changing the pathes?

You can set it like this:

config setprop pki CrtFile /etc/pki/tls/certs/cert.pem

okay, thank you very much. if i try to start the httpd service it says error in ssl.conf
SSLCertificateKeyFile: file ‘/etc/pki/tls/private/localhost.key’ does not exist or is empty what is true.
httpd.service: main process exited, code=exited, status=1/FAILURE

kill: cannot find process ""
systemd[1]: httpd.service: control process exited, code=exited status=1
systemd[1]: Failed to start The Apache HTTP Server.
systemd[1]: Unit httpd.service entered failed state.
systemd[1]: httpd.service failed.
Unit httpd.service cannot be reloaded because it is inactive.

Why would you do that? But even more to the point, how would you do that? The instructions call for your Cloudflare API key. If you don’t have a Cloudflare account, you don’t have a Cloudflare API key. So what did you enter as your API key?

In any event, the following should correct your problem and return you to a self-signed certificate:

config delprop pki CrtFile
config delprop pki KeyFile
config delprop pki ChainFile
signal-event nethserver-base-update

Once you’ve done that, confirm that the key file is again present:

ls -l /etc/pki/tls/private

because i did not read it carefully, it was my fault, sorry :frowning:

after doing that delprop and the baseupate
i got:
ls -l /etc/pki/tls/private
total 20
-rw-r–r-- 1 root root 1801 Dec 8 14:10 cert.pem
-rw-r–r-- 1 root root 1647 Dec 8 14:10 chain.pem
-rw-r–r-- 1 root root 3448 Dec 8 14:10 fullchain.pem
-rw------- 1 root root 0 Feb 16 11:16 httpd-admin.key
-rw------- 1 root root 0 Feb 16 13:50 localhost.key
-rw-------. 1 root root 1704 Dec 18 2016 NSRV.key
-rw-r–r-- 1 root root 1704 Dec 8 14:10 privkey.pem
localhost.key is empty :frowning:

What’s the output now of

config show pki

config show pki

According to the manual, that should have worked. Try

signal-event certificate-update
ls -l /etc/pki/tls/private
1 Like

now something changed.
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2018-02-16 14:45:43 CET; 1min 37s ago
Docs: man:httpd(8)
Main PID: 13873 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
├─13873 /usr/sbin/httpd -DFOREGROUND
├─14003 /usr/sbin/httpd -DFOREGROUND
├─14004 /usr/sbin/httpd -DFOREGROUND
├─14005 /usr/sbin/httpd -DFOREGROUND
├─14006 /usr/sbin/httpd -DFOREGROUND
└─14007 /usr/sbin/httpd -DFOREGROUND
but dont be able to get the webgui…

okay, now i got the webgui, uffffffff

1 Like

Thanks a lot for your support @danb35 and @mrmarkuz !!!

Just a question, because that was the reason why i try this, is it possible to use without Cloudflare to renew the certificat? Just for a single server and to renew the certificat?

As I wrote above, the method I described uses DNS validation. To effectively use that, your DNS host must be supported by I gave a link above to the documentation file that describes what DNS hosts are supported, and what you’d need to do to use each of them. If your DNS hosting is with one of those providers, you should be able to use this technique. If not, as a practical matter, you won’t (you can do DNS validation manually, but you’d need to manually update the DNS records for your domain every time you wanted to renew the cert).


Yeah! Readability has been improved now thanks for taking my suggestions into the account :slight_smile:

It might be an option to just open a port on the firewall for 2 minutes and have letsencrypt validate the certificate, then close the port again. This works for me.

If the location has no internet, maybe you can use your mobile phone to create an internet link, and use that for 2 minutes to verify the certificate.

1 Like

It can work, but it’s probably harder to automate. Lots of ways to skin this cat though.

In my case, I have a different web server behind my pfSense firewall, and ports 80 and 443 (among others) are forwarded there. I don’t think there’s a way I could script the changes to the port forwarding on the firewall, and I don’t think I’d want to anyway (I have a number of internal servers that are getting certs this way, so contention could be an issue–and I wouldn’t want to interrupt traffic to the machine that’s supposed to be the web server anyway).

Another option (and what I had been doing before I started messing with DNS validation) is to run the ACME client on the Internet-facing device, use that to get all your certs, and then script deployment of those certs to the various internal servers that needed them.

In my case, I use the renewal mail as input for a task that is manually executed on a spare public IP. No services run over it so it can be abused this way :slight_smile:

1 Like

Thanks for the HowTo and Wiki entry @danb35 - very helpful.

I had a minor glitch with OnlyOffice / Nginx not being able to verify the cert CA internally, so I added the ‘–fullchain’ option. Pointing nginx conf to /etc/pki/tls/certs/fullchain.pem instead of the cert.pem resolved that issue.