Security

Hi,

 

I'm having a hard time finding vendors who offer a service to sign Intermediate CA certificates for use within ClearPass(Guest).

Most SSL vendors immediately want to offer their PKI program for Web SSL certificates. When I mention that I need to have an Intermediate CA cert signed so I can issue device/profile-signing certs for MDM, they seem to be unaware of such offerings.

 

I have been given a mandate that we not be required to pre-install an untrusted (self-signed) Root CA cert on our devices prior to onboarding. We want everything to be trusted.

 

We are not a Microsoft-shop, so their PKI solution is not an option for us.

Any advice appreciated!

 

-David

Many of them offer them but not on their website. It generally costs thousands of dollars for this type of setup. You usually need to contact their sales departments directly. (Verisign, Thawte, Comodo)

Oh I've been in touch with their sales departments. Still getting the runaround. Have tried Thawte, Symantec [formerly Verisign], and Entrust so far.

 

We're more than willing to spend the money, if we can find a vendor who will take it!

 

:smileysad:

Try Digitrust. I know they used to do it.

David,

 

I would not expect any public Certificate Authority to offer that service in the way you ask it. If an CA would issue you an intermediate CA certificate, you can sign server and client certificates for any website/server/client in the world that would be trusted by all clients.

 

You also don't need that for Onboarding to work.

 

Onboarding uses two certificate infrastructures:

(1)- The public structure (Verisign/Digicert/Comodo/StartSSL) to sign the server certificate, so that clients trust your ClearPass server (both RADIUS and Webserver; can be the same server certificate).

(2)- The Onboard Client certificate server; which can be built int or external (MS PKI); and which can be stand-alone (option root) or part of an enterprise PKI (intermediate).

 

For the use-case of Onboarding, so users self-registering clients on your network, getting a client certificate, configure the users device to use that certificate to access the network, ONLY ClearPass needs to trust the Client certificate from (2). There is no need that your client certificates are globally trusted (by any system on the planet); if that need is there, you may have a problem with your design.

 

As all devices trust the server certificate from (1), certified by a public Certificate Authority; there is no need to install trusts in advance on your client devices. IOS users will get an untrusted profile the first time if they do not install the root certificate as step 1 in the Onboard process; they will be able to ignore and continue. That is what works for most customers.

 

So get a trusted server certificate for your ClearPass server(s); in the case of multiple servers, check the CPPM - Certificates 101 Technote on the support website (http://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Default.aspx?EntryId=7961) on the section about SAN (Subject Alternative Names).

 

I would advise to keep your Onboard Certificate Authority as 'root' or standalone, unless you have a very good reason and good understanding of what risks you are introducing by making it intermediate.

 

What you are asking: "that we not be required to pre-install an untrusted (self-signed) Root CA cert on our devices prior to onboarding" is possible without an intermediate public certificate, just a public server certificate.

 

Herman

Hi Herman,

 

Thanks for your reply (and thanks to all others who replied!). We have a public SSL cert (a wildcart cert) on ClearPass for the "HTTPS server certificate". So that part of the equation is covered and trusted by all devices.

 

The RADIUS server cert for 802.1x authentation is currently signed by the ClearPass onboard self-signed CA (Signing), and so, once the devices have the self-signed root CA installed, this is also trusted. I understand that I can use a (trusted, publicly signed) cert for RADIUS also, and in fact had this set up for a while when I first set up the 802.1x network.

 

So assuming both my RADIUS and my HTTPS certificates are signed by a trusted public CA, we still have the issue of profile-signing for iOS devices.

When a BYOD device is first onboarded, they are going to get a warning that the Device Enrollment profile (containing the SCEP request, RADIUS cert and WiFi configuration) is unverified. We are trying to eliminate that warning message.

 

The "Certificates 101" Technote states: "If you have no interest in authenticating/Onboarding any iOS devices then you will be good to go with self-signed certificates.". It mentions the web server cert (which we know is valid) and the "[cert for] 802.1x termination is also provisioned to the device to complete the trust chain.". I have installed an SSL cert as the RADIUS cert, and 802.1x connectivity works without any warnings.

However, this document doesn't mention once the profile-signing that happens when an iOS device is onboarded with CP. These Device Enrollment profiles are signed by the Onboard Local CA, which, unless you install the self-signed untrusted root CA is "Not verified" when prompted to install it (see attached PNG).

 

I guess it would just be nice to have a simple checklist of what certificates are needed to onboard iOS devices with no trust warnings or verification failures.

Thanks,

David

---

@sotnickd wrote:

Hi Herman,

 

 

However, this document doesn't mention once the profile-signing that happens when an iOS device is onboarded with CP. These Device Enrollment profiles are signed by the Onboard Local CA, which, unless you install the self-signed untrusted root CA is "Not verified" when prompted to install it (see attached PNG).

 

I guess it would just be nice to have a simple checklist of what certificates are needed to onboard iOS devices with no trust warnings or verification failures.

Thanks,

David

---

David,

 

As you keep mentioning in your note, it all comes down to the word of the day "Trust". :)

 

If you hit CPPM onboarding page with HTTPS URL you are going to get an error on the browser because the devices doesn't know who signed the https cert.

 

When you onboard a device the first step should always install the cert of the server who is generating the certificate. Hence the link for the root cert on the main page for IOS. 

 

If you are using SCEP with AD. There is a recent document posted on this on the support site.

 

http://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=13757

 

 

 

 

I just did a test with this last night using CPPM 6.3.2, AOS 6.4 and Windows Server 2012.

 

I didn't need to have any special certs on the .1x side. I just needed a publicly signed cert for the HTTPS for IOS devices to onboard.

 

One note is that for windows 8.1 devices you will need to have an 802.1x cert that has id-kp-eapOverLAN extended key usage

---

tarnold wrote: 

If you are using SCEP with AD. There is a recent document posted on this on the support site.

Therein lies the rub. We're not running AD.

 

This isn't an HTTPs certificate trust issue, it's an iOS-level trust issue. I think we are just going to have to give up on our quest for complete trust and force our users to install the ClearPass self-signed Root CA cert as step 1 of onboarding. This seems to be the way most places are doing it, as much as it pains me to have that initial unverified CA cert installation.

 

-David

David,

 

I don't know an option to make that profile trusted; without establishing that trust first.

 

What works in my experience are two options:

- User installs root certficate, and then the profile is trusted.

- User skips installation, profile is unverified and user can ignore that.

 

The warning is meant to warn users that the profile is untrusted, and I don't see how a device can determine if the profile is trusted unless you tell it it is trusted upfront. A classical chicken-egg situation.

 

May be others have found a work-around...

 

Herman

For those who happen upon this thread, and who manage to get tripped up by the Root CA documentation within ClearPass, I want to post my solution, which permits me to onboard using the self-signed ClearPass Root CA without any untrusted steps along the way.

 

What I learned is that as long as the certificate used to sign the iOS profile is trusted, then it doesn't matter if the payload contains self-signed certificates. iOS will trust them implicity as long as the profile is signed by a trusted source.

 

What I did in my case was to acquire a valid, signed code-signing certificate (from GoDaddy in our case), and use this certificate as the profile-signing cert within ClearPass. This certificate can be uploaded on the page: Onboard + WorkSpace > Deployment and Provisioning > Provisioning Settings and then clicking the Upload a Code-Signing Certificate link at the top of the page.

 

After I did this, the rest sort of fell into place. Another "trick" I learned is that iOS will install all the certificates in the chain of trust for the RADIUS (TLS) certificate. What this means is that you can "trick" the iOS device into installing your ClearPass root CA (self-signed) certificate onto the device as long as you use this root CA to sign the RADIUS certificate. I accomplished this by generating a CSR for the RADIUS cert within ClearPass, and then using the Root CA in ClearPass Guest to sign this CSR, and then installing the signed cert as the RADIUS cert. Since my use-case (installing additional MDM profiles with Casper/MobileIron) requires a root CA be installed, this worked out beautifully for us.

 

No self-signed or untrusted certificate warnings are presented to the user (everything is green) and we're good to go!

This is exactly what I've been trying to do.  Thank you.

How do you go about using the Root CA in ClearPass Guest to sign this CSR? Is there an option in the web interface or do you have to use and openssl command?  If so, could you show an example? 

FYI on private IP address in certs. The following is from GoDaddy

 

"Phasing out Intranet Names and IP Addresses in SSLs

 

The Internet security community is phasing out the use of intranet names and IP addresses as primary domain names or Subject Alternative Names (SANs) in SSL certificates. This is an industry-wide decision, not one specific to our company.

As of July 1, 2012, we no longer accept new requests, rekeys or renewals for SSL certificates that contain intranet names or IP addresses and are valid beyond Nov. 1, 2015. In addition, we do not support SSL certificates that secure public IP addresses or IPv6 addresses.

An intranet name is the name of a private network, such as server1, mail orserver2.local, that public Domain Name Servers (DNS) cannot access. An IP address is a string of numbers, such as 123.45.67.890, that defines a computer's location.

Why the change?

 

To create a safer online environment, members of the Certificate Authorities Browser Forum met to define implementation guidelines for SSL certificates. As a result, effective October 1, 2016, Certification Authorities (CAs) must revoke SSL certificates that use intranet names or IP addresses.

In short, this change increases security. Because internal server names are not unique, they are vulnerable to man-in-the-middle (MITM) attacks. In a MITM attack, the attacker uses a copy of the real certificate or a duplicate certificate to intercept and retransmit messages. Because CAs issue multiple certificates for the same internal name, an attacker can make a valid request for a duplicate certificate and use it for the MITM.

To read the CA/Browser Forum guidelines, click here."

 

 

I will try to see if I have a how-to, If not I will post one tomorrow.

---

@sotnickd wrote:

For those who happen upon this thread, and who manage to get tripped up by the Root CA documentation within ClearPass, I want to post my solution, which permits me to onboard using the self-signed ClearPass Root CA without any untrusted steps along the way.

 

What I learned is that as long as the certificate used to sign the iOS profile is trusted, then it doesn't matter if the payload contains self-signed certificates. iOS will trust them implicity as long as the profile is signed by a trusted source.

 

What I did in my case was to acquire a valid, signed code-signing certificate (from GoDaddy in our case), and use this certificate as the profile-signing cert within ClearPass. This certificate can be uploaded on the page: Onboard + WorkSpace > Deployment and Provisioning > Provisioning Settings and then clicking the Upload a Code-Signing Certificate link at the top of the page.

 

___________________________________________________________________________________

I purchased a Digicert code signing certificate and installed it in the location you suggested.  When setting up provisioning settings I can choose the cert for Windows code signing but it is not an available option for iOS signing. I chose use an uploaded certificate but the certificate drop down is empty.

 

Discovered I needed to install it as a provisioning cert.