First check your backups and see if you can re-install the Private Key. If you don't know how to re-install the key from your backups, then contact your systems administrator. Failing that, contact your server software vendor for technical support. The only alternative course of action available is a re-issuance of the certificate following the re-submitting of a replacement CSR.
There may not be a corresponding Private Key or the key that is found is not the one that matches the certificates.
You may also see this error: "OpenSSL: error:0B080074:x509 certificate outines:x509_check_private_key:key values mismatch"
Name based hosting is rarely used in production environments.
IP based hosting should be used due to the way that the SSL protocol works.
If the key file has a pass phrase you need to remove it, as Apache cannot read this on start-up, you can do that with the following command:
Openssl rsa -in file1.key -out file2.key
File2.key will contain your unencrypted key
If you used Mozilla to download the file, it may have saved the file in compressed format
I get 'The Page Cannot Be Displayed' when going to the HTTPS page
Is the SSL port opened, this is usually port 443. (Listen 443)?
Is the firewall set to allow the SSL port through?
Has the server been rebooted?
Make sure 'Use SSL 3.0' is ticked in the web browser options.
This error message occurs because there are directives missing from the httpd.conf file. Most web servers can be configured to 'talk' to various browser versions in a different way, the fix for this particular problem is to add the following directives to the httpd.conf file so allowances can be made for Internet Explorer on the Mac:
SSLSessionCache dbm:/var/cache/httpd/ssl_cache
SSLSessionCacheTimeout 300.
The error means that there are embedded objects or HTML tags on the page that are not being called absolutely secure. For example, a page that is loaded securely (HTTPS), and contains an image tag within the source code such as IMG SRC =http://www.yyy.com/image.gif. In this case the image is being called absolutely using the non-secure (HTTP) protocol.
The certificate is not bound to any specific IP address. It is bound to the fully qualified domain name such as www.digi-sign.com [1].
This problem occurs if you assign the same IP address to each host in your config file. SSL does not support name based virtual hosting (host headers are encrypted in SSL), so only the first certificate listed in your config file will be sent.
The Root Certificates and/or Intermediate Certificates may not be installed correctly. This can be checked by clicking on 'View Certificates' when you get the error message and seeing if all three certificates are visible.
It may also be that the certificate being used is not for the Fully Qualified Domain Name, check again using 'View Certificates' to see if the domain name on the certificate matches the domain name in the URL that you are going to.
Check your 'Internet Options' and make sure that 'Use SSL 3.0' is ticked in the 'Advanced' section.
Also ensure that SSL Protocol version 3 is supported.
The bundle file must also be specified in the Global SSL section of the. conf file.
If the web server is set to check the Certificate Revocation List and the server is down, this can cause a time-out of the operation.
This will not be the certificate, but something related to the browser timing out on the operation.
The first reason is that the SSL implementation in some MSIE versions has some subtle bugs related to the HTTP keep-alive facility and the SSL close notify alerts on socket connection close. Additionally the interaction between SSL and HTTP/1.1 features are problematic with some MSIE versions, too. You've to work-around these problems by forcing Apache with Mod_SSL or OpenSSL to not use HTTP/1.1, keep-alive connections or sending the SSL close notify messages to MSIE clients. This can be done by using the following directive in your SSL virtual host section:
Open the file with any text editor and carefully insert the code piece below in the appropriate place, around the directive for "SSLengine on", you may have to insert it in both the IF and the ELSIF portions of the setup:
$PerlConfig .= "Listen $ip:443\n";
$PerlConfig .= "
# ------------- INSERT THIS CODE -------------
$PerlConfig .= "SetEnvIf User-Agent \".*MSIE.*\" \\n";
$PerlConfig .= " nokeepalive ssl-unclean-shutdown \\n";
$PerlConfig .= " downgrade-1.0 force-response-1.0 \n";
# ------------- END INSERT -------------------
$PerlConfig .= "SSLengine on\n";
$PerlConfig .= "SSLCertificateFile /home/sites/$group/certs/certificate\n";
$PerlConfig .= "SSLCertificateKeyFile /home/sites/$group/certs/key\n";
$PerlConfig .= join('', @ssl_conf);
Additionally it is known some MSIE versions have also problems with particular ciphers. Unfortunately one cannot workaround these bugs only for those MSIE particular clients, because the ciphers are already used in the SSL handshake phase. So a MSIE-specific SetEnvIf doesn't work to solve these problems. Instead one has to do more drastic adjustments to the global parameters. But before you decide to do this, make sure your clients really have problems. If not, do not do this, because it affects all (!) your clients, i.e., also your non-MSIE clients.
Links:
[1] http://www.digi-sign.com