Security

Hi all,

First, let me preface this by saying I know pretty much NOTHING about certificates, including many of the acronyms.  (Please don't shoot me... never had cause to learn about certificates.  I DO know what SSL stands for, though! :) )  So, I may need a bit of hand-holding with a solution.  But here's what I have, and where I'm running into a problem.

I realize this may make things more complicated, but we have a wildcart certificate for our domain through DigiCert.  They call it their WildCard Plus product.  It's so that we can buy one certificate and use it on ALL of our web servers that require SSL certificates.  DigiCert lets you request a "duplicate" certificate with the common name of the specific server as one of the SANs.  The certificate's primary name is still *.powayusd.com.  So in this case, I have a duplicate certificate for cppm.powaypusd.com.  I downloaded the certificates from DigiCert and got 3 files:  TrustedRoot.crt (I believe this is the certificate for the DigiCert root CA); DigiCertCA.crt (intermediate CA, I believe); and star_powayusd_com.crt (the actual SSL certificate.)

First problem:  In CPPM (not Onboard or Guest), under Administration --> Certificates --> Server Certificate, the first entry has the certificate for *.powayusd.com, the second entry (Intermediate CA Certificate) has the DigiCert intermediate CA, and the third entry (Root CA Certificate) has the DigiCert root CA.  When I connect a device to our secure server using simple username/password authentication (e.g. an iPad, tap on SSID, enter username and password, accept certificate, done), the certificate comes up and says "Not Trusted."  This is on an iPad.  The name of the certificate shows up as "*.powayusd.com."  I'm not sure if this is because the iPad doesn't trust DigiCert as a CA, or if it's a complication of using the wildcart certificate, or something else.

Second problem:  In Onboard --> Certificate Authorities, I defined a new CA.  When I created the new CA, I choose the "Root CA" mode.  Fast forward to creating a Configuration Profile and Provisioning Settings.  When I go to onboard my Mac Mini, after importing the certificate, Keychain Access shows the "ClearPass Onboard Local Certificate Authority" but shows that it is not trusted.  (I assume this is because I'm using ClearPass Onboard as the root CA.)  Then, after installing my enrollment profile, my Mac connects successfully, but the profile shows "Unverified" next to the profile name in System Preferences --> Profiles.  Since, when onboarding devices, our staff would much rather see "Verified" than "Unverified," I'm trying to figure out how to make this happen.

I have tried creating a new CA in Onboard, using both the "Intermediate CA" and "Imported CA" modes. 

When I chose "Intermediate CA," it created a new CSR.  I copied that CSR, went to DigiCert, requested a duplicate certificate, pasted the CSR, gave it the name (cppm.powayusd.com), and a few minutes later, I had a new certificate to download.  It contained the same 3 filenames as for ClearPass up above.  When I try to import the Internediate CA file (DigiCertCA.crt), it comes back and tells me "The private key does not correspond to any of the available certificates."  Never mind that it never prompted me for a private key file; there as only one "Browse" button next to "Certificate."  If I try to import the Trusted Root file, I get the same message.  If I try to import the star_powayusd_com.crt file, I get "Certificate is not a CA," which of course, it's not. 

When I chose "Imported CA," it wants both a certificate file and a private key file.  I don't have a private key file.  When I try uploading any of the .crt files, I get the same "The private key does not correspond..." message.

As I mentioned, and as I'm sure you've figured out, I don't have a clue how to proceed with this.  Any advice will be greatly appreciated.  Thanks!

1. You should never use a wildcard certificate as a RADIUS certificate.
2. The "not trusted" message is a normal part of using EAP. It has nothing to do with PKI trust, it is simply saying, "This is the first time you've connected to this network, are you sure you trust this server."
3. Did you click the cert from the Onboard enrollment screen (step 1) or did you try to do it a different way?

Essentially here's the flow:

Install Root CA

- This makes the enrollment profile and configuration profile show up as Verified

Install Enrollment profile

- This does the background certificate enrollment via SCEP and then sets the wireless configuration.

Thanks for the response, Tim!

Commenting on what you said:

1) Wasn't my choice...

2) OK, that's good to know.  Some people would get worried when they saw "Not Trusted" when connecting their devices to our secure network.  I told them just ignore that; I guess I was mostly right. :)

3) Yes.  I browse to my CPPM onboard page, log in, then I get "Install certificate."  Click that, it installs the certificate in Keychain Access (which is also where, when you click on the certificate, it shows "This root certificate is not trusted" at the top).  Then, I click "Install Profile," which downloads and installs the profile to the Mac and configures the wireless.  It all works, but the profile shows "Unverified."

Where you said "here's the flow," Step 1 "Install Root CA" seems to be where I'm unsure.  I defined a root CA, but when I choose the "Root CA" mode, it says right on the button, "The certificate authority has a self-signed root certificate and issues client certificates locally."  I'm getting stuck when trying to use either the "Intermediate CA" or "Imported CA" modes.

1. The wildcard issue is major. You should acquire a standard SAN certificate.
2. /
3. When you go to install the root CA, does it prompt you for your local computer credentials?

Are you trying to have ClearPass be the root CA for BYOD devices? The other less common options are integrating with ADCS or if you have your own public intermediate signing CA. Those are the two use cases where you would use the intermediate option.

On #1, easier said than done when management is involved.......

3) Yes, the Mac prompts me for local admin credentials so that it can make modifications to the keychain.

To answer your other question, they're not BYOD devices, but rather, district-owned devices that need to authenticate via certificates.  But yes, I'd like to have ClearPass be the CA if that's possible.  That's how it's working now; I'm just seeing that "Unverified" all the time and it's driving me nuts.

Thanks!

Here's an update:

I think it's an OS X thing.  When I install the certificate on an iPad, as you (Tim) said earlier, it comes up saying it isn't trusted, so I tap Trust.  Then, when it installs the second certificate, the iPad actually DOES show "Verified."

On the Mac, I found that if I go into Keychain Access, highlight the ClearPass Onboard entry, do Get Info, expand "Trust," and then tell it to always trust that entry, then it shows Trusted in the Keychain.  And afer doing that, when I install the provisioning profile mobileconfig file, then it will show "Verified."  Interesting workaround, but it seems to work.  Not that it really matters that much, but I think it makes people feel better when they see that nice green "Verified" instead of big red "Unverified."  So now I guess the question becomes, is there a way to get the Mac to trust the ClearPass Onboard certificate in the Keychain automatically, rather than having to force it to trust it?

Thanks!

Did you ever answer your question? - So now I guess the question becomes, is there a way to get the Mac to trust the ClearPass Onboard certificate in the Keychain automatically, rather than having to force it to trust it?

We are asking the same question at the moment. Is there any way of automating this. We are working with students and too many steps creates too many problems. 

Thanks!

During the Onboard process, the user will be prompted to download the CA certificate which will open keychain access and prompt the user to enter their computer credentials.

This is standard for any CA that gets installed.

If you have a Digicert wildcard certificate. You can contact Digicert support and ask to get a duplicate certificate with your your clearpass server FQDN as the CN and it will then work. (you have to submitt a new CSR)
Example:

clearpass server =cppm.mydomain.com
Wild card is CN=*.mydomain.com
You can request for free a duplicate certificate with the CN=cppm.mydomain.com and have SANs of cppm1.mydomain.com,cppm2.mydomain.com,cppm3.mydomain.com.
For my domain I did 10 SANs for all of my clearpass servers, they said that they could do more than 10 SANs but it had to be done on the backend.

---

@cappalli wrote:

1. The wildcard issue is major. You should acquire a standard SAN certificate.
2. /
3. When you go to install the root CA, does it prompt you for your local computer credentials?

 

Are you trying to have ClearPass be the root CA for BYOD devices? The other less common options are integrating with ADCS or if you have your own public intermediate signing CA. Those are the two use cases where you would use the intermediate option.

 

 

---

---

@cappalli wrote:

1. The wildcard issue is major. You should acquire a standard SAN certificate.
2. /
3. When you go to install the root CA, does it prompt you for your local computer credentials?

 

Are you trying to have ClearPass be the root CA for BYOD devices? The other less common options are integrating with ADCS or if you have your own public intermediate signing CA. Those are the two use cases where you would use the intermediate option.

 

 

---

It is poor security practice to use the same certificate for EAP and HTTPS.