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:
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 install.sh script)
The domain is my primary domain
Thanks!
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.
-Eric
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 :( Who can tell where I can return old values via command line?
This issue was resolved here:
https://www.virtualmin.com/node/18614
Hi,
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??
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443
# 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.
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
# 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.
#<Location />
#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]+$/
#</Location>
# 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
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# 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"
</VirtualHost>
I’m a “Geek” serving as a Linux System admin, a website designer and maintainer and general know how for all things TECH. I am a fan of CentOS, Virtualmin, Joomla, and anything that uses Electricity. See more of my posts at http://www.dieskim.me
Yup, you should be able to remove that ssl.conf file without causing any problems.
-Eric
Thank you again for the help!
I’m a “Geek” serving as a Linux System admin, a website designer and maintainer and general know how for all things TECH. I am a fan of CentOS, Virtualmin, Joomla, and anything that uses Electricity. See more of my posts at http://www.dieskim.me
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?
-Eric
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).