SSL Certificate update not being picked up

So I am new to virtualmin and am loving it! I just have one issue that I have not been able to resolve. I have updated my SSL cert to my CA signed one from Virtualmin -> Server Config -> Manage SSL Cert. The new certificate appears correctly under current SSL cert details and I have copied it to Webmin, Usermin, Dovecot, and Postfix successful (and they are using this cert, all is well there). But when I hit my website, I still get a certificate warning showing the old, self signed certificate.

I am sort of losing my mind as to how this is even possible.

Steps I’ve tried:

  • Manually installing the cert by coping the cert/key into the domain's home directory
  • Verified the httpd.conf file is correctly pointing at the cert/key
  • Tried installing again using the New Cert tab
  • Restarted httpd several times

I really don’t even know where the old cert is living or how this is possible. Any direction or where I can investigate further would be greatly appreciated.

Virtualmin: 3.83.gpl GPL
Fresh install of CentOS 5.5 (used script)
The domain is my primary domain


I was able to work around this by directly editing the ssl cert/key path in /etc/httpd/conf.d/ssl.conf to match what is in my virtual server’s conf. The deceleration in that file is VirtualHost default:443. For the future, should i remove this default virtualhost deceleration from ssl.conf? I’m wondering if it’s being loaded first and since only one SSL cert can be loaded, if that is why it is overriding my virtual server…

Thoughts? Thanks!

Hmm, I haven’t heard of a declaration in ssl.conf overriding what goes in other VirtualHost blocks.

It is possible that Apache just needed to be restarted?

While Virtualmin should restart Apache for you whenever updating the SSL cert, if it didn’t for some reason, that could cause the problems you saw.


Thanks for the response Eric. I also don’t understand why the default block would override the block specific to that host, but that seems to be what is happening. The docroot still comes out right (but it is my default domain, so it might just be getting lucky).

I have restarted apache several times.

I believe I’m having the exact same problem as you right now… might be a bug?

It might be a bug, but it seems like an Apache bug not one in Virtualmin. From what I can tell Virtualmin is creating the VirtualHost correctly.

For now, I would recommend editing conf.d/ssl.conf and changing the key locations to match the domain you would like to use ("/home/domain/ssl.key")

Uploaded a renewed cert, and while Virtualmin reflect the updated cert, apache doesn’t seem to be serving it in HTTPS requests.

– I checked and the ssl.key and ssl.cert files are updated on the domain’s home directory.
– using virtualmin 3.76 on Debian 5.0.6 OS, Apache 2.2.16
– godaddy cert.
– restarted apache, no change

I have successfully created SSL Certificate and added to one of my virtual hosts. But then, as they say curiosity killed the cat, I noticed very much inviting copy buttons in Virtualmin and pressed the first one, I guess I have copied it to Webmin and… can’t access Virtualmin anymore :frowning: Who can tell where I can return old values via command line?

This issue was resolved here:


I was having the same issue where my default domain would not load its new SSL but still load some kind of default cert from somewhere.

After many hours I found that it might be the /etc/httpd/conf.d/ssl.conf that contained a section - after checking with my other server I saw that it does not have this section - removing it fixed the problem.

Is it safe to remove this section from “/etc/httpd/conf.d/ssl.conf” - will this not break anything in Virtualmin/Apache??

General setup for the virtual host, inherited from global configuration

#DocumentRoot “/var/www/html”

Use separate log files for the SSL virtual host; note that LogLevel

is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSL Engine Switch:

Enable/Disable SSL for this virtual host.

SSLEngine on

SSL Protocol support:

List the enable protocol levels with which clients will be able to

connect. Disable SSLv2 access by default:

SSLProtocol all -SSLv2

SSL Cipher Suite:

List the ciphers that the client is permitted to negotiate.

See the mod_ssl documentation for a complete list.


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

Server Certificate Chain:

Point SSLCertificateChainFile at a file containing the

concatenation of PEM encoded CA certificates which form the

certificate chain for the server certificate. Alternatively

the referenced file can be the same as SSLCertificateFile

when the CA certificates are directly appended to the server

certificate for convinience.

#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

Certificate Authority (CA):

Set the CA certificate verification path where to find CA

certificates for client authentication or alternatively one

huge file containing all of them (file must be PEM encoded)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

Client Authentication (Type):

Client certificate verification type and depth. Types are

none, optional, require and optional_no_ca. Depth is a

number which specifies how deeply to verify the certificate

issuer chain before deciding the certificate is not valid.

#SSLVerifyClient require
#SSLVerifyDepth 10

Access Control:

With SSLRequire you can do per-directory access control based

on arbitrary complex boolean expressions containing server

variable checks and other lookup directives. The syntax is a

mixture between C and Perl. See the mod_ssl documentation

for more details.

#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

and %{SSL_CLIENT_S_DN_O} eq “Snake Oil, Ltd.” \

and %{SSL_CLIENT_S_DN_OU} in {“Staff”, “CA”, “Dev”} \

and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \

or %{REMOTE_ADDR} =~ m/^192.76.162.[0-9]+$/


SSL Engine Options:

Set various options for the SSL engine.

o FakeBasicAuth:

Translate the client X.509 into a Basic Authorisation. This means that

the standard Auth/DBMAuth methods can be used for access control. The

user name is the `one line’ version of the client’s X.509 certificate.

Note that no password is obtained from the user. Every entry in the user

file needs this password: `xxj31ZMTZzkVA’.

o ExportCertData:

This exports two additional environment variables: SSL_CLIENT_CERT and

SSL_SERVER_CERT. These contain the PEM-encoded certificates of the

server (always existing) and the client (only existing when client

authentication is used). This can be used to import the certificates

into CGI scripts.

o StdEnvVars:

This exports the standard SSL/TLS related `SSL_*’ environment variables.

Per default this exportation is switched off for performance reasons,

because the extraction step is an expensive operation and is usually

useless for serving static content. So one usually enables the

exportation for CGI and SSI requests only.

o StrictRequire:

This denies access when “SSLRequireSSL” or “SSLRequire” applied even

under a “Satisfy any” situation, i.e. when it applies access is denied

and no other module can change it.

o OptRenegotiate:

This enables optimized SSL connection renegotiation handling when SSL

directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ “.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars

<Directory “/var/www/cgi-bin”>
SSLOptions +StdEnvVars

SSL Protocol Adjustments:

The safe and default but still SSL/TLS standard compliant shutdown

approach is that mod_ssl sends the close notify alert but doesn’t wait for

the close notify alert from client. When you need a different shutdown

approach you can use one of the following variables:

o ssl-unclean-shutdown:

This forces an unclean shutdown when the connection is closed, i.e. no

SSL close notify alert is send or allowed to received. This violates

the SSL/TLS standard but is needed for some brain-dead browsers. Use

this when you receive I/O errors because of the standard approach where

mod_ssl sends the close notify alert.

o ssl-accurate-shutdown:

This forces an accurate shutdown when the connection is closed, i.e. a

SSL close notify alert is send and mod_ssl waits for the close notify

alert of the client. This is 100% SSL/TLS standard compliant, but in

practice often causes hanging connections with brain-dead browsers. Use

this only for browsers where you know that their SSL implementation

works correctly.

Notice: Most problems of broken clients are also related to the HTTP

keep-alive facility, so you usually additionally want to disable

keep-alive for those clients, too. Use variable “nokeepalive” for this.

Similarly, one has to force some clients to use HTTP/1.0 to workaround

their broken HTTP/1.1 implementation. Use variables “downgrade-1.0” and

“force-response-1.0” for this.

SetEnvIf User-Agent “.MSIE.
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

Per-Server Logging:

The home of a custom SSL log file. Use this when you want a

compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”

Yup, you should be able to remove that ssl.conf file without causing any problems.


Thank you again for the help!

I have just seen the same issue on a new server: Centos 6

Removed the section from ssl.conf, restarted apache, now I get the correct certificate response.

This was a difficult problem to diagnose, as my application showed the correct certificate… but when Google Checkout API called back, it received a cert error because the default VM self-signed cert was returned.

With any ot these changes - changing of the paths or removing the entire section, Apache just refuses to start giving this empty error.
Failed to start apache :
Starting httpd: [FAILED]

I have the same problem.

Does Apache start up after removing (or renaming) the ssl.conf file in your case?


Just want to add that I get this too. Installing SSls are fine for me, but this one in particular was copied to Webmin et al. It is that one which now wont work on Apache. Restarted Apache OK.

Updating “ssl cert/key path in /etc/httpd/conf.d/ssl.conf to match what is in my virtual server’s conf” did not work initially. So I then changed my virtualserver to be the servers default, and then restarted apache and it seems to be working now.

Eitherway, seems an issue that needs to be fixed!

Just had the same issue on vps boxes running centos 6 & 7. removing the section from ssl.conf fixed the issue (took me about 6 hours to get here though).