Copying SSL certs to firewalled servers

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: sudo certbot --apache -d

It produced this output: Obtaining a new certificate

My web server is (include version): apache 2.4.6

The operating system my web server runs on is (include version): CentOS 7

My hosting provider, if applicable, is:

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

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


Can you explain your problem?

Thank you

Hi! If the above is public, could you change the domain name to ‘’? Thanks…
Our network techs use the same domain name for both internal & external domains - The external domain is hosted by a 3rd party provider, while the internal domains are hosted in-house in Active Directory. I have a number of internal Linux web servers that require SSL certs, & the team doesn’t want to act on an internal CA. To get around this, I asked for a subdomain be created ‘’ both internally & externally, built a server ‘’, got an external IP assigned, added a virtual host (‘’) to it, & adding the virtual host to my /etc/hosts file with the same IP as it’s parent, had a certificate deployed. Issue : I have other servers on that I would now like to copy the SSL cert to (& every 90 days update them with the cert updated on this outward facing server). Is this a/the right way to do it & how should I proceed?


if you are using active directory, why not use an internal ca. Active directory can easily push CA to client machine.

Anyway, I think you can use Rsync( for Linux) if you wish to use public ca. Try search in this forum and you probably can find others doing this way.(not sure what windows can use)

Thank you.

I will search thru the forum, confirm what needs to be rsync’d, rsync it, & if I still experience issues, I’ll be back. Very appreciative of your fast response

Back from vacation - allow me to start from the beginning
Environment :
External domain = Hosted externally
Internal domain = Hosted internally
Caveat : I am NOT the network admin - I must work with what I am given. And my esteemed colleagues do not know how to push CAs & do not want to research

What I want : Attach ssl certs to internal (non-Internet facing) apache web servers;,

What I did :

  1. Had our AD admins create on our internal domain
  2. Built the web server
  3. Built a virtual host on the encrypt server
  4. Asked our external DNS provider to NAT the internal IP so as to make it accessible to Let’s Encrypt

What I’ve got : Let’s Encrypt ‘successfully enabled Report : Certificate name mismatch


(PuppetMaster :slight_smile: cd /etc/puppet/modules/common/templates
vi httpd_conf.erb

IncludeOptional conf.d/.conf
<% if @hostname == ‘encrypt’ then -%>
IncludeOptional sites-enabled/
<% end -%>

vi hosts.erb encrypt
<% if @hostname == ‘encrypt’ then -%> www
<% end -%>



Our public DNS server must allow traffic to the encrypt server over port 80 & 443; which means it needs a public IP


/bin/yum -y install mod_ssl python-certbot-apache

Virtual Host

/bin/mkdir -p /var/www/
/bin/chown -R $USER:$USER /var/www/

/bin/cat > /var/www/ <<!

... ... !

sites subdirectories not necessary, but …

/bin/mkdir -p /etc/httpd/sites-available
/bin/mkdir -p /etc/httpd/sites-enabled

/bin/cat > /etc/httpd/sites-available/ <<!
<VirtualHost *:80>
DocumentRoot /var/www/


ln -s /etc/httpd/sites-available/ /etc/httpd/sites-enabled/


sudo certbot --apache -d
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Created an SSL vhost at /etc/httpd/sites-available/
Deploying Certificate for to VirtualHost /etc/httpd/sites-available/
Enabling site /etc/httpd/sites-available/ by adding Include to root configuration

Congratulations! You have successfully enabled

You should test your configuration at:

You successfully issued a certificate for your domain on March 13 (it's public in Certificate Transparency), but that certificate isn't being served by your server. Instead, your server is serving a self-signed certificate.

Does this work from inside your network, or not at all? If not at all, you might have a _default_ virtual host with the old self-signed certificate or something that's taking priority over the Certbot-installed one.

There's also the DNS challenge, where you can get certificates by changing DNS records—this is often a good option for sites that have problems allowing inbound connections. But since your certificate was successfully issued, that's not the particular problem that you're facing right now.

I am very appreciative of the fast response, as well as ashamed of my public display of ignorance …I’ve been out of networking too long

If I understood you correctly the public-facing server did it’s job (domain cert issued). Next step is to pass that on to its internal counterparts. What I’m getting is the following : uses an invalid security certificate. The certificate is only valid for


Changes I made:
httpd.conf : ServerName
ssl.conf : ServerName
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/

That's correct because you only asked for it to be valid for when you obtained it:

Perhaps because of the terms used I’ve been looking at this wrong, because traditionally the certs are issued per server. What I would like to see are valid certs on *, which is why i did the -d (domain?). How would I phrase that, as a wildcard (-d *

-d is the way of specifying a subject name in Certbot and the exact name you requested after the -d goes into the certificate request.

Wildcards do contain the *. at the beginning but one thing that’s worth knowing is that (by PKI standards) the wildcard doesn’t apply to the base domain at all. So if you get a certificate that covers *, it doesn’t cover; you need to explicitly include both if you want to cover the base domain too.

-d "*" is the right way to request a wildcard but if you want a wildcard certificate, you should know that Let’s Encrypt only began offering them about a month ago and by Let’s Encrypt policy they’re only available via DNS challenges (proving control by creating a specified TXT record in your DNS zone). So if you need a wildcard certificate, you’ll need to figure out how to do the DNS challenge method rather than the inbound HTTP challenge method. If not, you’ll get an error that means that the certificate authority insisted on the DNS authentication method but that your client failed to complete it. Again, this distinction is a matter of Let’s Encrypt’s issuance policy.

Let me see if I can get our external DNS provider to do that for us. Thank you very much for your help

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