Hi…happy new year… (now that’s out of the way :)… this is my second time posting for help (not the same issue)… the first time I found a template of questions about my setup to fill out, but don’t see that this time, so will improvise…

I am running apache httpd 2.4.6 on RHEL7.
Domain is and
You will see “uhero-file” in the cert… this is, I believe, the A record name of the host, but I only want the cert to operate on the two CNAMEs as shown.
I installed certbot via yum with python2-certbot-apache package.
Here’s what happened:

$ sudo certbot --apache --domains,
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
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf
Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration
Deploying Certificate to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.

1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Redirecting vhost in /etc/httpd/conf/httpd.conf to ssl vhost in /etc/httpd/conf/httpd-le-ssl.conf

Congratulations! You have successfully enabled and

You should test your configuration at:

and then the usual boilerplate at the end. It looks like I’ve got a mismatch on names, but I don’t understand what could cause this. Apparently I have “trust issues” lol. ACTUALLY this is the second time I’ve been through this cert-getting process. After initial failure and breaking my site royally, I deleted the old cert, and reverted my httpd configs (glad to be using git for this) back to a working (http) state. Figured I’d just go one more time from scratch. And yet, it still tells me that my cert is valid starting from Nov 29 2018, which might be the first time I requested a cert, but I thought I had deleted that cert?

And btw, I told it I wanted to redirect, but no redirect is happening. Which is just as well because it means I can leave the site as-is until Wed and probably no one viewing it - not expecting to use https - will notice the current cert problem.

Help much appreciated.


Hi @dji,

Can you see if you have a file in /etc/httpd that declares a VirtualHost for _default_:443? If so, could you please send me the whole configuration in /etc/httpd so I can try to better debug this recurrent bug with Certbot?

But this case you could probably fix things by simply getting rid of the _default_:443 VirtualHost or changing it to something like instead of _default_.


Thanks for quick reply @schoen. You want my whole config dir tree, not just the file that has the _default_ VH? If so I can tar or zip it up, but what would be the preferred medium for sending? Also, about fixing the _default_, can I change it to * ? I have these two domain names and not sure which I should choose, if only one, although ideally I want to redirect the one with www. to the one without, but don’t know enough apache yet…
edit: I see that DM on this forum has an upload option… will try that.
edit edit: Learned the hard way that the forum won’t allow that kind of DM attachment.


Commented out the VirtualHost _default_ from where it appears (conf.d/ssl.conf), and that fixed the problem I reported, but weird side effect is that some stuff on the site (html/css/js stuff) is actually broken as a result! I wonder if this is because some code is being downloaded dynamically from elsewhere, and the secure connection is interfering with that. I don’t know the internals of this site and hope I don’t have to dig in to debug it…


This is likely symptomatic of a mixed content problem, where the site includes subresources such as CSS and Javascript over HTTP while the main page was loaded via HTTPS. Recent browser versions will block these subresources by default rather than loading them over HTTP, in order to prevent downgrade attacks that would undermine the security of the HTTPS on the main page. This could be true for loading jQuery or something remotely via HTTP, for example.

You can try to try to diagnose this, if that appears to be the case.


I sent a private message asking for you to send me the configuration by e-mail (thanks for your help with that!).

closed #7

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