Security

Hello All,

 

We had setup Onboard Provisioning on CPPM 6.0.2 a few weeks back and this was working just fine. However, please note that we are not utilizing a Commercial Certificate. We are instead utuilizing Microsoft Active Directory as a Root CA as we are only Onboarding Windows PCs that are members of the Domain in Active Directory.

 

However, when we upgraded to CPPM 6.1.0 a few days back, Onboarding stopped working. At anytime we attempt to connect to the SSID created for Onboarding, we get a redirect (designed this way) to a Web Page using HTTPs and then we now get the error launched on the Web Page saying "Onboard provisioning can not be performed at this host address".

 

However, if we modify CPPM by unchecking the option to use HTTPs, we get the Web Login page come up just fine. 

 

Don't know what could be wrong at this point. This was working just fine before we upgraded.

 

Any ideas anyone?

 

 

Were you able to figure this out?

I am having the exact same issue.

 

I have a test CPPM VM setup running version 6.1.0.24441

I setup a test device provisioning page.

I have uploaded our commerical cert as the CPPM server certificate.

 

Under ClearPass Onboard > Onboard > Provisioning Settings >

 When I click on "Test" on the test Provisioning Settings profile I setup I get

"Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator."

I did what eosuorah suggested and disabled the HTTPS requirement and it allows me to access the page.

Is there something I am missing?

 

I don't recall encountering this issue under 6.0.2.x

 

This is from the Application Log:

Client:    192.168.15.254:60945
Script:    /guest/device_provisioning2.php
Function:  
Arguments: array (
  'error' => 1,
  'message' => 'Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator.',
  'disable_login' => true,
)
Details:   array (
  'host' => 'cppm.testserver.com',
  'common_name' => '*.testserver.com',

Hi Bourne,

 

Now I'm a bit concerned based on your response below. I haven't installed a Commercial Certificate as of yet.

 

I intend to do that in a few weeks. But it seems, you installed a Commercial Certificate and you are still having the issue.

 

Now, that's definitely a concern if the Commercial Certificate doesn't resolve the issue. I was told by Aruba that a Commercial SSL Certificate should fix this problem.

 

 

 

 

bourne wrote:

Were you able to figure this out?

I am having the exact same issue.

 

I have a test CPPM VM setup running version 6.1.0.24441

I setup a test device provisioning page.

I have uploaded our commerical cert as the CPPM server certificate.

 

Under ClearPass Onboard > Onboard > Provisioning Settings >

 When I click on "Test" on the test Provisioning Settings profile I setup I get

"Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator."

I did what eosuorah suggested and disabled the HTTPS requirement and it allows me to access the page.

Is there something I am missing?

 

I don't recall encountering this issue under 6.0.2.x

 

This is from the Application Log:

Client:    192.168.15.254:60945
Script:    /guest/device_provisioning2.php
Function:  
Arguments: array (
  'error' => 1,
  'message' => 'Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator.',
  'disable_login' => true,
)
Details:   array (
  'host' => 'cppm.testserver.com',
  'common_name' => '*.testserver.com',

---

 

Hey eosuorah,

 

So you did talk with Aruba directly about this issue?

I was thinking about calling them as well because I stumped on this issue.

 

We have installed a commercial cert as I mentioned. It is a Go Daddy cert with Unlimited Sub domains.

 

I suspect that perhaps from the ClearPass Onboarding side of things the certificate is messed up somehow.

 

There must be something wrong with the config though because I have seen other posts related to Onboarding under 6.1.0.x and no one else has reported this issue. 

 

Based on the technotes and looking at the interface the Onboarding portion of the CPPM underwent a major overhaul.

 

Hopefully someone can shed some light on this. Are you still working with the option for HTTPS turned off?

At this point, the CPPM is not in production as of yet.

 

And yes I actually do have a Ticket opened with Aruba on this issue. However, I am waiting on the Customer in order to load the Commercial Certificate. And we are looking at using GoDaddy as well.

 

I was told that security was beefed up on CPPM Version 6.1. Didn't have this issue on Version 6.0.1 and yet, I was using Microsoft Active Directory as the Certificate Authority.

 

Please keep me updated on your outcome if you get it to work. I will also keep you posted too.

 

This is quite strange though.

Oh that is good it isn't in production!

 

I definitely believe that security was beefed up. I was pretty shocked the first time I looked at the Onboarding section in the new version of CPPM.

 

Go Daddy should work well. I had it setup in a test environment under CPPM version 6.0.1 and it worked like c hamp. Solved all the issues we were having with Onboarding Apple devices when the require HTTPS option is enabled.

 

And yeah I haven't had any issues either with Onboarding under any of the previous version. Even under 3.9 CP Guest & Onboard.

 

I will keep you posted though if I find something.

And if you hear back on your ticket that would be awesome if you could pass along the information

 

Thank you!

 

Cheers

 

================================

 

Sorry one other question.

Under ClearPass Onboard > Onboard > Provisioning Settings

 If you click one of the profiles (sorry not sure what else to call them) there is an option to click "Test" to test the weblogin page.

I was curious what the resulting URL is?

 

For me it does something weird when "Require HTTPS" is enabled. Instead of filling in the name of the cppm or the ip address it simply puts a *

  Something like this: http://*.domainname.com/onboard/device_provisioning2.php

 

I'm assuming it is doing this because of the how our commerical cert is setup?

If I replace the * with the name of the CPPM that is when I receive the error mentioned previously.

 

If the option for "Require HTTPS" is off then the IP of the CPPM Management port is filled in where the star was. Which is similar behavior to version 6.0.2 

 

I doubt it matters but I just thought I would mention it and ask about it.

 

Actually when I hit the "Test" button, I don't get that "*" you seem to notice. I get the full error message.

 

However, i haven't loaded any commercial certificates as of yet. So maybe that's why.

 

I will for sure keep you posted.

Thanks for checking!

 

Will keep you posted as well. Going through the release notes now for 6.1.0 to see if there is something that stands out.

 

Cheers

In 6.1 we do a full name comparison on the certificate and if you have either an IP or a FQDN and they don't match what CPPM expects you will get the error. If you install a commercial cert you will not get that error unless the name format does not match.

 

example: Onboard: cplab.clearpassdemo.com

                 Cert:        cplab.clearpassdemo.com   ----GOOD

 

                 OnBoard: cplab.clearpassdemo.com

                 Cert:          CPlab.clearpassdemo.com -----BAD

 

                 OnBoard: cplab.clearpassdemo.com

                 Cert:          cplab.clearpassdemo.com:8081 -----BAD

 

In the patch coming out in the next couple weeks will allow you to use different capitalizations or add a port for NATing. 

 

Hi,

 

Our commercial cert supports multiple sub domains.

So our cert when it gets installed shows as *.ourdomain.com

 

On my test CPPM under Onboard I setup a new Root CA for testing. Is it the common name of the certs it is checking?

 

Is there a log that we can check that will show this?

 

Sorry I am having a bit of a hard time wrapping my head around what exactly is causing the issue

 

===========================================

 

Okay I just confirmed it.

I redid the certificate on the Policy Manager. I set the CN to equal that of the hostname of the server as well the DNS name we are using. I can now get the Onboard page using HTTPS.

 

So Aruba is no longer supporting commercial certs that are setup for multiple subdomains? i.e. *.ourdomain.com?

 

This is definitely going to be a problem for us!

In the CPGuest side look under 

Home » Administration » Support » Application Log

 

and it will show what it compared and why it errored

Okay now this log makes sense:

 

Client:    192.168.15.254:63959
Script:    /onboard/device_provisioning2.php
Function:  
Arguments: array (
  'error' => 1,
  'message' => 'Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator.',
  'disable_login' => true,
)
Details:   array (
  'host' => 'testcppm.ourdomain.com',
  'common_name' => '*.ourdomain.com',
)

 

I am assuming that the last part of this where it says Details:   array...

This is what is being compared and this is what is indicating the failure?

 

If Aruba will not allow the wildcard character then our commercial cert is going to be a problem.

I believe the patch will also cover wildcard certs.

 

I am checking with engineering and will post it when I find out. Its late in the day so I don't know if I will get an answer today.

Hi Tarnoid,

 

Is it still possible to use Microsoft AD as a Root CA on CPPM 6.1.0?

 

 

Hey tarnold,

 

I understand it's late. I very much appreciate your feedback!

 

If you could confirm with engineering that would be great!

I will keep an eye on this post for your response.

 

Thank you again!

 

Cheers

 

@eosuorah sorry man I sort of highjacked your thread. My appologies.

Yes.

 

This is just a comparison of the cert on CPPM and is it matching what is being presented to the client.

 

If you use MS as the root you are making CPPM an intermendiate.

Interesting. I was told that I need to use a commercial certificate.

 

It was working with MS on 6.0.1. After I upgraded, it broke and started giving me the same error.

The commercial cert is for the CPPM side which is the web server cert.

 

For onboarding it can be your MS cert.

So if I reference the Application Log, I should be able to establish a root cause of my issue? Same place as stated below. Right?

 

In the CPGuest side look under 

Home » Administration » Support » Application Log

 

 

Correct. The CRS request you sent to your MS should have exact FQDN Name as your cppm.

And if doesn't match, I have to request another CSR again. Right?

 

This time making sure it matches. Correct?

This was sent to me awhile back when ask about the change

6.1 adds an additional check to ensure that when you are using SSL, you are accessing the server using the same hostname as that specified in the certificate.

When this check fails, you get the "Onboard provisioning cannot be performed at this host address" message.

If you see this message, it is a symptom of a configuration problem somewhere in the network.

The reason this check was added is that if you try and proceed, iOS provisioning will fail. It is better to catch the error early.

Yes

I was told that for us to onboard IOS, I require a Commercial Certificate.

 

Is that correct? Can I use MS to Onboard IOS Devices too?

iOS Onboarding will fail if HTTPS is on.

iOS requires that the Policy Manager certificate (the certificate of the web server (Apache)) be a commercial certificate.

 

This is one of the reasons why we purchased a commercial certificate.

 

The Onboarding CA can remain self-signed, or in your case Microsoft

 

Someone please correct me if I am wrong

Onboarding is different than the CPPM cert. that can be a self signed/intermediate/or imported.

 

The only one that needs to be commercial is the CPPM cert which is also the webserver cert.

That makes sense. I remember building the Onboarding to be a Self Signed. But the CPPM part was referencing MS.

 

I worked on 6.0.1. But after we upgraded, it stopped working.

 

 

Guys, where does the CPPM Cert come into play?

 

Is it solely for the purpose of IOS Devices? If I was just onboarding Windows Machines existing on the Customer's Domain and I use MS as the Root CA and CPPM as an Intermediate CA. Shouldn't I be able to onboard the Windows PCs?

 

 

I think you will be able to Onboard Windows machines yes.

 

But with Apple it will more then likely fail if HTTPS is enable.

 

With Apple, if HTTPS is enable and you attempt to Onboard it, during the Onboard process you will even hit a point (I believe it is when Apple attempts to install the profile) that the Onboard process will fail with an error pertaining to the Apple profile.

 

If you disable HTTPS then you will have no problem Onboarding Apple. The downside is that any information exchanged during this process is done in plain text.

 

So the CPPM cert comes into play during the actualy Onboarding process and it only really matters for Apple devices. Windows and Android devices don't have a problem with the CPPM cert if it isn't a commercial one and HTTPS is required.

 

If you are never intending on Onboarding Apple devices then you could probably get away with not having a commercial cert.

 

I could be wrong about this but I think it is recommended to keep the Onboarding CA and the CPPM cert as seperate entities. 

Don't quote me on this but I thought I had read that somehwere.

 

Check this post http://community.arubanetworks.com/t5/ClearPass-formerly-known-as/CPPM-and-Onboard-Apple-device-issues/td-p/65828

Thx Bourne.

 

That has been my understanding that I only require a commercial cert for IOS since they only utilize HTTPs. Others are good to go.

 

But for some reason, my Windows Machines stopped working after I upgraded to 6.1.

 

Will look at the Application Logs and see what the root cause is.

 

 

Most likely it will be in your access tracker logs where the issue is. It may just be a trust issue and you need to read your MS certs back into the trust list. 

 

Are you having an issue during onboarding or just authenticating?

OK so reading back on your thread from what you are discribing is that the CPPM cert is your issue.

 

You need to make sure the name on the certs FQDN is the same on your CPPM. If it worked fine and then stoped working after you upgraded to 6.1, you should be able to see the error in the application log on the CPGuest side just like bourne was able to.

 

 

Client:    192.168.15.254:63959
Script:    /onboard/device_provisioning2.php
Function:  
Arguments: array (
  'error' => 1,
  'message' => 'Onboard provisioning can not be performed at this host address. If you were redirected here, please contact a network administrator.',
  'disable_login' => true,
)
Details:   array (
  'host' => 'testcppm.ourdomain.com',
  'common_name' => '*.ourdomain.com',
)

 

 

 

If you can.. try redoing the server cert for the CPPM and make the CN equal to the whatever the FQDN name you are using to access your CPPM with and see if it works then. That is what I did after tarnold explained what the log was actually saying.

 

Once I did that it worked.

 

Not sure if you have that type on freedom with your testing though.

 

If eosuorah is getting the error message then he is more then likely not even getting a chance to attempt to authenticate as this message pops the second you attempt to access the Onboarding page.

 

This also means that there will be no information in the Access Tracker.

 

He might have to take a closer look at the Application Log mentioned earlier

It doesn't even onboard anymore. It just generates that error.

 

It doesn't get to the option where it sends you to the "Quick Connect" link.

 

 

Look in the applicaion log and post what it shows there.

I will get that on Monday as the CPPM is currently at the Customer's location.

 

 

@eosuorah

 

Any luck checking the Application Log?

Nope. However, now we are gettting the "Onboard provisioning can not be performed at this host address" Error anymore.

Now we are getting an "Internal Server Error 500 - Page cannot be displayed".

 

When we disable the need to use "HTTPs" it works like a charm.

Once we enable "HTTPs", it gives us the "Internal Server Error 500 - Page cannot be displayed".

 

We imported an SSL Certificate and this did not help at all. 

 

However, we then checked the Application Logs and got a Fatal Error for the times we tried attempting to access the Onboard Provisioning URL. Can't remember what that error is. The Avaya Team is looking into that.

 

But I will ask for the error and post it up here.

Is this on a controller or IAP?

 

tarnold wrote:

Is this on a controller or IAP?

---

IAP deployment.

 

 

What firmware version?

There is a known bug where https does not work on 3.3. If you downgrade to 3.2.0.1_36986 it should work.

---

@tarnold wrote:
What firmware version?

There is a known bug where https does not work on 3.3. If you downgrade to 3.2.0.1_36986 it should work.

---

I will confirm and let you know.

---

@tarnold wrote:
What firmware version?

There is a known bug where https does not work on 3.3. If you downgrade to 3.2.0.1_36986 it should work.

---

The weird thing though is that when we perform a Test directly from ClearPass, the same "Internal Server Error 500" error occurs.

 

So, we are not even going through the IAPs at this time.

 

I believe it's an issue with the ClearPass itself. I'm trying to get the error captured from the Application Log and I will post it here on the forum.

 

See below for the error captured from the Application Log:

 

Client: 10.40.100.72:61864

App User: admin

Script: /guest/device_provisioning.php

Function: NwaPhpFatalErrorHandler

Arguments: array (

)

Details: array (

  'type' => 1,

  'message' => 'Call to undefined function NwaCurrentWebHost()',

  'file' => '/opt/amigopod/www/_include/NwaCore/NwaMdpsOnRadiusWebLoginPage.func.php',

  'line' => 16,

)

I haven't read the entire thread, so perhaps this answers has already been provided. In that case, apologies for the redundancy.

 

The cause for this error is that the CN in the SSL certificate of the Clearpass server does not match the name (FQDN) used for redirection.

 

Often users do have a proper SSL certificate installed, but the redirection URL is either using a wrong name (not the name specified in the CN) or using the IP address.

 

In this case the onboarding process will fail. We now detect this earlier in the process and this is why this message appaers on the first screen. In the past users would be able to continue, but then later  during the onboarding process it would fail with a message like "invalid profile".

 

A CN / FQDN mismatch is always the case with wildcard certifiactes.

 

Wildcard certificates are not supported for onboarding. Even in case we would allow the onboarding process to continue, IOS and OSX-Lion devices will not trust wildcard certificates.

(And Windows does not support Wildcard certificates for PEAP btw)

 

So in most cases the solution to this problem is making sure the hostname as specified in the certificate CN is resolved to the Clearpass (Virtual) IP address and the redirection url is specified using https://<FQDN =CN>/guest/device_provisioning.php.

 

I hope this helps.

 

Ben

---

@bvz wrote:

I haven't read the entire thread, so perhaps this answers has already been provided. In that case, apologies for the redundancy.

 

The cause for this error is that the CN in the SSL certificate of the Clearpass server does not match the name (FQDN) used for redirection.

 

Often users do have a proper SSL certificate installed, but the redirection URL is either using a wrong name (not the name specified in the CN) or using the IP address.

 

In this case the onboarding process will fail. We now detect this earlier in the process and this is why this message appaers on the first screen. In the past users would be able to continue, but then later  during the onboarding process it would fail with a message like "invalid profile".

 

A CN / FQDN mismatch is always the case with wildcard certifiactes.

 

Wildcard certificates are not supported for onboarding. Even in case we would allow the onboarding process to continue, IOS and OSX-Lion devices will not trust wildcard certificates.

(And Windows does not support Wildcard certificates for PEAP btw)

 

So in most cases the solution to this problem is making sure the hostname as specified in the certificate CN is resolved to the Clearpass (Virtual) IP address and the redirection url is specified using https://<FQDN =CN>/guest/device_provisioning.php.

 

I hope this helps.

 

Ben

---

Hi Ben,

 

We are not using Wildcards in generating the SSL Certificates.

 

I believe the URL points to just the Hostname of CPPM but the CN on the SSL Certificate references the FQDN of CPPM.

So for example, assuming the FQDN of our CPPM is clearpass01.aruba.com which was what we used as the CN on the SSL Certificate.

 

Our URL instead goes to https://clearpass01/guest/device_provisioning.php. So you are saying that this is the problem?

 

Are you saying it should be https://clearpass01.aruba.com/guest/device_provisioning.php instead?

 

And to modify this, we go into the Provisioning Page and modify the Web Login Tab?

 

Look forward to your response.

 

 

Correct, the onboarding should be accessed using  https://clearpass01.aruba.com/guest/device_provisioning.php

You change this on the NAS, i.e the device doing the redirection. On Aruba Controllers, this would be the Captive portal profile.

 

Before changing the controller profile, you could validate this by simply pointing your browser to this page. You should not get a Certificate warning on this case.

 

Regards,

 

Ben

---

@bvz wrote:

Correct, the onboarding should be accessed using  https://clearpass01.aruba.com/guest/device_provisioning.php

You change this on the NAS, i.e the device doing the redirection. On Aruba Controllers, this would be the Captive portal profile.

 

Before changing the controller profile, you could validate this by simply pointing your browser to this page. You should not get a Certificate warning on this case.

 

Regards,

 

Ben

---

I agree it needs to be done on the NAS as well. However, when we perform a "Test" on the Provisioning Page. It automatically results to https://clearpass01/guest/device_provisioning.php.

 

So this needs to be changed somewhere within ClearPass as well. Right?

 

 

Just confirmed that the FQDN shows up on the URL. So everything seems okay. 

 

But something is broken on CPPM.

 

Client: 10.40.100.72:61864

App User: admin

Script: /guest/device_provisioning.php

Function: NwaPhpFatalErrorHandler

Arguments: array (

)

Details: array (

  'type' => 1,

  'message' => 'Call to undefined function NwaCurrentWebHost()',

  'file' => '/opt/amigopod/www/_include/NwaCore/NwaMdpsOnRadiusWebLoginPage.func.php',

  'line' => 16,

)

Hello bvz,

 

Thank you for your reply.

For the situation that I am facing, which I think a little different now from that of eosuorah, tarnold was able to help identify that it is indeed a CN/FQDN mismatch as you mentioned.

 

However, this probelm appears to only exist in version 6.1 of CPPM.

I have done tests with a lower version of CPPM (I believe it was 6.0.1) using a wildcard certificate and the Onboarding of an Apple device and it worked fine with the requirement for HTTPS enabled. I also tested with Windows and Android and in all situations I had a successful Onboard.

 

I am a little surprised to read that wildcard certificates are not supported for Onboarding, especially since I had posted on this forum asking for recommendations on certificates and it was never stated that wildcard certificates were not supported.

 

That being said, if wildcard certificates will not work then they will not work and I guess we will be forced to invest in another certificate. 

 

Is there a document from Aruba that covers supported certificates specifically? The reason I ask is because I had read over the documentation for CPPM numerous times and never came across anything that mentioned what certificates are recommened. Only that commercial certificates are recommended.

 

Thank you again,

 

Cheers

Correct, this is a new check in Clearpass 6.1.

Before, we allowed accesing the page even when there was an SSL Certificate warning. But users would get problems later during the actual onboarding.

Interesting fact you wrote that IOS onboarding did work with your wildcard certificate. 

Does your Wildcard certificate contains a Subject Alternate Name (SAN) with the real hostname perhaps?

 

Ben

Hi Ben,

 

No our wildcard certificate does not contain a Subject Alternate Name (SAN) that is equal to the FQDN.

I can't explain why it worked and unfortunately we do not have the test environment anymore. I would a little time

to get one set back up to test this all over again.

 

Thank you though for the additional information about Aruba's/Apple's support for wildcard certificates.

 

It appears we will have to go back to the drawing board.

 

Cheers

Right, that is under Administration -> Server Configuration. There you can specify the hostname. Unfortunately changing the hostname requires leaving the AD domain if joined to a domain. After the hostname change you can re-join.

Ben

Thx Ben.

 

But the CN on the SSL Certificate (which is an FQDN) matches the name on the URL redirect (which is also an FQDN).

 

So not too sure what the deal is here.

Dear eosuorah,

 

Before opening a TAC case for this, you may want to check if following is the case:

 

Do you redirect to the onboarding page on a Clearpass subscriber node perhaps?

In this case, the subscriber node will proxy the onboarding request to the publisher (by design). However a bug exsited in the 6.1 code which caused problem with proxying https. This has been corrected in the latest cumulative patch (6.1.1) available on our support site.

If this isn't the case, and/or you still have problems, I suggest you contact TAC for this who can help furher troubleshooting the issue.

 

Regards,

 

Ben

I don't have a Subscriber Node.

 

I have a Ticket with TAC already.

We had to rebuild the CPPM Server. Removed the VM image. Re-installed and re-configured Onboarding.

 

Onboarding worked just fine.

 

Weird one!