Forum Discussion

david_baumgart_'s avatar
david_baumgart_
Icon for Cirrus rankCirrus
Jul 29, 2016

How to properly create Intermediate SSL Certificate

Hello all. I believe this should be an easy question but i need some guidance. I am publishing Skype for Business reverse proxy services with a Big IP and I am using the iApp to do so. I can get my mobile clients to connect and sign in through the reverse proxy and I can do a lot of what needs to happen, but sometimes I can't connect to calls on my phone and when I run into the issue I also simultaneously get a certificate warning stating that the Godaddy certificate that i purchased and set up on my reverse proxy could not be verified. This is making me think that I set this up wrong somewhere.

 

So what I did was I exported the certificate as a .pfx from my Edge server with it's private key and imported it to my F5 unit where I imported it as:

 

Import Type: PKCS 12 (IIS) Certificate Name: Skype_Public Certificate Source: PFX I exported Password: ********** Key Security: Normal

 

Then for the chain certificate I imported the godaddy bundle (labeled gd_bundle-g2-g1). There is also a PKCS7 certificate labeled as gd-g2_iis_intermediates but i couldn't get it imported into the Big IP and i was fairly confident it needed the bundle anyway. I imported the bundle as follows:

 

Import Type: Certificate Certificate Name: Skype_Public_Bundle Certificate Source: gd_bundle-g2-g1

 

Then in the iApp i just went and set it to create a new client ssl profile and used the Skype_Public-PFX.crt as the ssl certificate and used Skype_Public_PFX.key as they Key. Finally I used the Skype_Public_Bundle.crt as my intermediate cert, fired up the iApp, and could sign in with my phone. But i got the above errors so I am thinking I dropped the ball somewhere as i am relatively inexperienced with SSL certificates.

 

application delivery
BIG-IP
iApps
skype for business

2 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 29, 2016

    The next thing you'll want to do is actually perform a cryptographic verification of the chain. You'll need two files:

    1. The web server certificate used in your client SSL profile

    2. A bundle file containing all of the CAs used in your client SSL profile chain. If the root CA is not in that chain (it shouldn't be), add that to the test bundle file

    From the BIG-IP command line, or any *NIX system that has OpenSSL:

    openssl verify -verbose -CAfile [bundle file] [web server cert]

    You want to see something like this:

    [web server cert]: OK
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 29, 2016

    Troubleshooting certificate issues is never easy, but the first thing you should probably do is simply verify that you have all of the necessary certificates in the chain. A certificate digitally signs the certificates that it issues, so in a multi-link chain with a root and potentially several subordinate CAs, each certificate in the chain will have a cryptographic relationship with the certificate next to it, either as the signer or signee. The process of verification must then "walk" the chain and verify each signature along the way (against the signer's public key), and the chain must be complete (from end-entity all the way to the explicitly trusted self-signed root).

     

    If you look in the certificates section of the BIG-IP GUI, under System - File Management, you'll see the server certificate and bundle. First look at the server certificate and not the issuer. Now go to the bundle, find that issuer, find its issuer, and walk through the bundle until you get the self-signed root (subject and issuer are the same).

     

    Now, during the SSL handshake the server will send its certificate, and the certificates from the bundle. The bundle should not, however, contain the root CA. Assuming the client already has and explicitly trusts the root CA, the intermediate CAs in the bundle should provide the client with all of the additional links in the chain to build a complete end-to-end chain from the server cert to the root. If you're getting a verification error, it's very likely that you're missing one of these certificates. You may also need to check the client (mobile device) to make sure it has the root. Looking at the subject and issuer in the properties of the certificates is pretty straight forward, and hopefully you'll spot something that way. But it's not a "true" indicator as certificates can sometimes use the same names. The only accurate way to know is to cryptographically verify the chain, which can be done with various tools including OpenSSL. Before we dig into that mess though, makes sure you're not missing anything by name.