You need to use TLS SNI to be able to present two different certificates on the same listening port. Be aware that some clients, notably most browsers running under Windows XP, do not support SNI.
See the sni
option in the documentation. Split your certificates into different files (the same private key is used for both public certificates):
[https]
cert = /etc/ssl/domain.com.pem
accept = 443
connect = 80
[domain]
sni = https:domain.com
sni = https:www.domain.com
cert = /etc/ssl/domain.com.pem
connect = 80
[manager]
sni = https:manager.domain.com
cert = /etc/ssl/manager.domain.com.pem
connect = 80
Two things you can do:
- Verify the intermediate chain
- Clean up the intermediate chain
Verify the intermediate chain
As the error seems to indicate, there is something off about your intermediate certificate chain. You should check where you got your certificate from and that you got the correct intermediate bundle.
You should verify the "hash" and "issuer's hash" of every certificate in the chain with the openssl x509 -noout -hash
and openssl x509 -noout -issuer_hash
commands. Try this to get the issuer hash of your certificate:
cat /path/to/cert/mysite.com.cert | openssl x509 -noout -issuer_hash
Then try to find a certificate with this hash in the sf_bundle.crt
file that you specified as SSLCertificateChainFile
. You may have to extract the certificates (or just copy paste them to the command):
cat first_cert_from_sf_bundle.crt | openssl x509 -noout -hash
Check all of them. If none have this hash, then something is wrong right there. Keep doing these checks until you find a certificate which has the same -hash
and -issuer_hash
. This is your root certificate.
If something is missing, you can check the other intermediate files here https://certs.starfieldtech.com/anonymous/repository.seam. Download these and compare their -hash
against the -issuer_hash
where you got stuck.
If everything is okay, then ....
Clean up the intermediate chain
I have seen this also help when you get odd validation errors. Make sure that your intermediate chain lists only the required certificates and in the correct order (it is easier if it is in PEM format). In other words, if your chain is Your cert -> cert A -> cert B -> Starfield Root cert
. Try appending these in this order (you can skip the first and last) so your intermediate chain looks something like this:
-----BEGIN CERTIFICATE-----
cert A
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
cert B
-----END CERTIFICATE-----
I personally like to keep all these certificates (personal certificate, followed by intermediate ones, followed by the root certificate) in the same file. Then I just specify this file as both the SSLCertificateFile
and SSLCertificateChainFile
.
Best Answer
The
CAFile
option configures a CA to use for client authentication certificates; this isn't what you want.Instead, you want to craft the file in the
cert
option to contain the entire applicable certificate chain. You'll want to save a backup copy of that file, then make a new one; basically combining the two files, formatted like this:This will force stunnel to present the full certificate chain to clients.
One further tidbit; the
openssl s_client
command is very useful for testing certificate chain issues and checking how your service is presenting its certificates.Edit: Ok.. that certificate bundle's chain is three-deep, but the trust chain looks two-deep. Something's not right.
The top certificate ("Starfield Secure Certification Authority") is signed by an issuer named "Starfield Class 2 Certification Authority" with a thumbprint starting with
ad7e1c28
.. but the second cert in the bundle, named exactly the same as the first cert's signer, which should be the exact same certificate, has a thumbprint starting with363e4734
, and an expiration date 10 years earlier. Then the third (root) cert is the signer of the included intermediate cert.. but neither of those two has any relation to the first one!If that didn't make sense, don't worry. Summary: sloppy work, someone seriously dropped the ball building this cert bundle. Your best bet, then, is to export the files in base-64 format from a browser that's successfully validating the chain, pasting them into the format that I listed from there.
Since that's a confusing mess through no fault of your own, I took a guess at your DNS name and grabbed the cert, and I think this should be the full chain you need: http://pastebin.com/Lnr3WHc8