No, Apache users should use the bundle file from Aust Secure. If you do not install the bundle file you will receive not trusted messages when you go to the secure area of your web site.

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.

There is no difference, the process is the same and the directives used are the same.
Apache fails on start up, what could cause this?
If the key file has a passphrase 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.

The certificate is not bound to any specific IP address. It is bound to the fully qualified domain name such as www.austdomains.com.

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 is usually caused by the directive SSLCertificateChainFile being used instead of the SSLCACertificateFile directive.

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.

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 used.

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 Option' and make sure that 'Use SSL 3.0' is ticked in the 'Advanced' section. Check your .conf file to ensure that SSL Protocol version 3 is allowed.

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 certificates, but something related to the browser timing out on the operation.

When I connect via HTTPS to an Apache with Mod_SSL or OpenSSL server with Microsoft Internet Explorer (MSIE) I get various I/O errors. What is the reason?

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-aware virtual host section: SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

Additionally it is known some MSIE versions also have problems with particular ciphers. Unfortunately you 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 you have 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 of your clients.

Apache-SSL uses a toolkit called OpenSSL for its security routines. OpenSSL is very particular about the format of certificate requests and certificates. This error is specifically related to the format of the certificate.

Check that there are 5 dashes before and after the BEGIN and END text, and they must form the first and last lines of the certificate.

In particular, the BEGIN and END lines must look like:
-----BEGIN CERTIFICATE-----
Encoded Certificate
-----END CERTIFICATE-----

Be careful when you cut and pasted the certificate from the browser window into a text editor to create the certificate text file. Make sure you remove any trailing spaces, before and after the BEGIN or END lines, or you will see this error.

Specify the correct private key for the certificate.
Compare the modulus of certificate against the modulus of the private key to see if they match by using the following commands:

To view the certificate modulus:
openssl x509 -noout -text -in certfile -modulus

To view the key:
openssl rsa -noout -text -in keyfile -modulus

Check that the certificate and private key is saved in notepad and that it has no trailing spaces.

The "modulus" and "public exponent" portions in the key and the certificate must match exactly.

This error message occurs if you are using the incorrect certificate or private key during installation. So you need to use the matching key and certificate files. To check that the public key in your cert matches the public portion of your private key, view both files, and compare the modulus values with the following instructions:

To view the certificate:
openssl x509 -noout -text -in certfile
To view the key:
openssl rsa -noout -text -in keyfile

The "modulus" and "public exponent" portions in the key and the certificate must match exactly. If the "modulus" do not match exactly then you are using either the incorrect private key or certificate.

SSLCertificateChainFile can be used instead of SSLCACertificateFile, but Apple MACs may give errors regarding trust of the certificate, they may not see the intermediate certificate.

The ApacheSSL documentation, and the documents for the SSLeay toolkit, refers to certificates and certificate requests as "PEM" (Privacy-Enhanced Mail) files. They are not. ApacheSSL, like all SSL secure servers, uses the (standard) X.509 certificate format. SSLeay stores them in BASE64 encoded format, between '-----BEGIN-----' and '-----END-----' lines. BASE64 encoding was defined as part of the (old) Privacy Enhanced Mail (PEM) specification, which is why the documentation calls them "PEM format" files. Some web servers do use the Privacy-Enhanced Mail (PEM) format certificate packet (e.g., old Lotus Domino, 4D WebSTAR Server Suite/SSL). Do not select this format! Use the default "Standard" format, which is the BASE64 encoded X.509 certificate.

If the key file has a passphrase 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.

The problem might be that 56bit export versions of MSIE 5.x browsers have a broken SSLv3 implementation which badly interacts with OpenSSL versions greater than 0.9.4. You can either accept this and force your clients to upgrade their browsers, or you downgrade to OpenSSL 0.9.4, or you can workaround it by disabling only the ciphers which are causing the problem. SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP This also lets the broken MSIE versions work, but only removes the newer 56bit TLS ciphers.