ssl certificate - Multiple SSL certs with Stunnel

19
2014-04
  • Errol Fitzgerald

    I have purchased two PositiveSSL certs (seperately), one for manager.domain.com and another for domain.com. Originally I only needed manager.domain.com using SSL, but than I needed to use SSL on domain.com. Everything works fine with the one SSL cert for domain.manager.com, but when I add in the 2nd certificate data to the .pem file, domain.com tries to verify using domain.com's cert, and it doesnt work. How can I have two ssl certs using the same instanse of stunnel? I amusing nginx, and varnish also if that is useful.

    Here is the stunnel config file, and format of my pem file. Note - this will work fine for domain.manager.com (which is the first cert).

    cert = /etc/ssl/all.pem
    debug = 5
    output = /var/log/stunnel4/stunnel.log
    
    [https]
    accept  = 443
    connect = 80
    

    And the format for the all.pem. The first cert is for manager.domain.com (which works), and second is for domain.com, which does not work. (The private key was generated with manager.domain.com):

    -----BEGIN PRIVATE KEY-----
    MIIEvwIBADANBgkahkiG9w0BAQEFAASCBKkwggSl444AAoIBAQDz/pbylQ5Ci6ji
    END PRIVATE KEY-----
    -----BEGIN CERTIFICATE-----
    MIIFCjCCA/gdfwIBAgIRAL9QPhnM0h2smePkZ8ToSBMwDdfgKoZIhvcNAQEFBQAw
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIIFCjCCA/gdfwIBAgIRAL9QPhnM0h2smePkZ8ToSBMwDdfgKoZIhvcNAQEFBQAw
    -----END CERTIFICATE-----
    

    I have also tried separating the certs and putting them into a CApath

    CApath = /etc/stunnel/certs/
    debug = 5
    output = /var/log/stunnel4/stunnel.log
    
    [https]
    accept  = 443
    connect = 80
    

    I use the commands

    openssl x509 -hash -noout -in domain.pem
    openssl x509 -hash -noout -in manager.domain.pem
    

    to create the files to put in the dir /etc/stunnel/certs/. But stunnel gives the following error when trying to restart:

    Restarting SSL tunnels: No limit detected for the number of clients
    signal_pipe: FD=3 allocated (non-blocking mode)
    signal_pipe: FD=4 allocated (non-blocking mode)
    stunnel 4.42 on i686-pc-linux-gnu platform
    Compiled with OpenSSL 1.0.0e 6 Sep 2011
    Running  with OpenSSL 1.0.1 14 Mar 2012
    Update OpenSSL shared libraries or rebuild stunnel
    Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6
    Reading configuration from file /etc/stunnel/https.conf
    PRNG seeded successfully
    Line 8: End of section https: SSL server needs a certificate
    str_stats: 53 block(s), 3974 byte(s)
    [Failed: /etc/stunnel/https.conf]
    You should check that you have specified the pid= in you configuration file
    

    The files given to me for manager.domain.com are

    Root CA Certificate - AddTrustExternalCARoot.crt
    Intermediate CA Certificate - PositiveSSLCA2.crt
    Your PositiveSSL Certificate - manager_domain_com.crt
    

    and the same for domain.com.

    Can someone please help me on this?

  • Answers
  • Shane Madden

    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
    
    www.faultserver.com
    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
    

  • Related Question

    ssl - How do I ensure that stunnel sends all intermediate CA certs?
  • Jack Stahl

    A few computers, but not most, are rejecting the SSL certificate from my webserver. The problem seems to be that some computers are rejecting the CA certs. The problem seems to be manifesting on Mac OS X 10.6 when it is not fully updated.

    According to http://www.sslshopper.com/index.php?q=ssl-checker.html#hostname=beta.asana.com -- there's no problem.

    According to http://certlogik.com/sslchecker/, there's no intermediate certs being sent down.

    My cert is from Starfield Technologies, and I'm using sf_bundle.crt from here: certs.godaddy.com/anonymous/repository.seam

    I'm handling SSL on my server via stunnel with the following stunnel.conf:

    cert = $CODEZ/admin/production/proxy/asana.pem
    CAfile = $CODEZ/admin/production/proxy/sf_bundle.crt
    pid =
    client = no
    
    [<forwarded port>]
    accept = 443
    connect = 8443
    

    Any ideas what I could be doing wrong?


  • Related Answers
  • Shane Madden

    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:

    -----BEGIN CERTIFICATE-----
    (certificate from asana.pem file pasted here)
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    (intermediate certificate here; copy-paste the top chunk from the bundle)
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    (root certificate here; copy-paste the bottom chunk from the bundle)
    -----END CERTIFICATE-----
    

    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 with 363e4734, 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

  • Ben W

    Qualys SSLLabs is really handy for checking your configuration after changes.

    https://www.ssllabs.com/ssldb/analyze.html

    Checks that you've got

    • strong ciphers enabled
    • weak ciphers disabled
    • the certificate chain complete and in the correct order