Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

Cisco NAC Guest Controller 2.0.3. as a hotspot

Here's my conundrum we currently have a NGS on an internal address witha valid PKI cert against our internal CA.  In order to fascilitate using the NGS as a Hotspot for our Guest Wireless I am looking at moving it into a DMZ and giving it a public address.  Currently I am not seeing a simple way of acheiving this whilst maintaining both the internal cert and the publically sign cert. 

What would be the best approach?

- leave the NGS where it is and NAT to public (signed address) to the private address? 

- nothing and put up with a URL showing an internal address and having security pop-ups (least ideal approach from security point of view).

- Move to DMZ on public address and live without AD sign-on allowed via PKI certs?

- Phone a friend?

I'm a little lost in the woods here, and the clock is ticking....any pointers would be greatly received thanks!!

P.S. I have no problem making the Hotspot itself work against our controller my issue is around the best practice approach to making all my SSL certs both public and private live happily together?

3 REPLIES
New Member

Re: Cisco NAC Guest Controller 2.0.3. as a hotspot

Why are you putting it on the DMV? Security? Basically is a radius server with the added Cisco logo at the POST screen. Do u have more than 1 Ngs? If so are u going to load balance them? If so I would apply the ssl certified on the LB, best to use Ngs to create the certificate else you have to apply the private key manually to Ngs.

Sent from Cisco Technical Support iPhone App

New Member

Re: Cisco NAC Guest Controller 2.0.3. as a hotspot

Here's my problem, put another way -

I have an internal host (NGS) with an internally signed cert  via our CA (for admin access using active-directory).  This box will serve as a  hotspot for wireless clients.  Therefore it needs to be publically trusted too  on virtually any device.  I was thinking of physically moving the box and giving  it a publically routable address and then publically signing a cert against  this, technically I believe this would break our internal ca approach which is  still required for admin access (via active-directory). 

So here's my other thought, and the caveat here is my host  (NGS) must support multiple certs.  We leave the box physically where it is.   Add the public cert against the name = ngs.a.b.c (4th level domain) and this is statically nat'd on our firewall to the internal real address of our box. 

Since the public cert is signed against the name and not the IP this should stand up to scrutiny.  Would I be right in this assumption?
In an ideal world, I don't want to expose wireless clients to our internal IP address schema, which is what will heppen when using the NGS as a Hotspot (reason I was thinking of moving it to a DMZ) - So my other thought is to give it (NGS) an address that does not relate to our current internal schema.
The 2 key drivers here are security and useability - sometimes the two don't go hand in hand, but I am not prepared to sacrifice security in favour of useability...  that's just plain asking to be owned...
New Member

Re: Cisco NAC Guest Controller 2.0.3. as a hotspot

This is now resolved and done in the following way:-

The NGS is now a public entity as far as our network is concerned both for internal management (sponsors) and for client authenitcation/hotspot activity (guest wireless).  This being the case we purchased a public SSL certificate for our chosen hostname and installed it as follows:-

Caveat here is most public CA's will only sign a request which has a bit depth of at least 2048 bits! 

From CLI of NGS -

Step 1>  Create a 2048 bit key & temp certificate:

openssl req -new -newkey rsa:2048 -nodes -x509 -days 365

-keyout /etc/pki/tls/private/localhost.key

-out /etc/pki/tls/certs/localhost.crt

Step 2> Copy and set permissions for Postgres:

cp /etc/pki/tls/certs/localhost.crt /var/lib/pgsql/data/server.crt

chmod 600 /var/lib/pgsql/data/server.crt

chown postgres:postgres /var/lib/pgsql/data/server.crt

cp /etc/pki/tls/private/localhost.key /var/lib/pgsql/data/server.key

chmod 600 /var/lib/pgsql/data/server.key

chown postgres:postgres /var/lib/pgsql/data/server.key

Step 3 > Reboot the NGS (although I suspect restarting the HTTP daemon would have the same effect)

Step 4 > Once the above steps have completed and the NGS has rebooted you can

     create a CSR, via the UI:

     Admin > Server > SSL Settings > Create CSR .  Complete the additional

     fields,  do NOT check 'regenerate private key'.

     After this you can download the CSR via the download CSR link.

< ----------------------------- >

Get your CSR signed by the CA of your choice

< ----------------------------- >

Install you signed certificate on the NGS as follows:-

Pre-requisites are that you have the following certs -

          - Server Certificate in PEM format

          - Root Certificate in PEM format

          - Intermediate Certificate in PEM format

All must end in a .pem extension.

For the purposes of this post we shall call these server.pem, root.pem and intermediate.pem.

openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM

1. Using sftp or scp upload the intermediate and root certs to /etc/pki/tls/certs.

2. in a root shell:

cd /etc/pki/tls/certs

chmod 666 *.pem

cp intermediate.pem localhost.chain.crt

cat root.pem >> localhost.chain.crt

3. Edit /etc/httpd/conf.d/ssl.conf

Find the line starting:#SSLCertificateChainFile

Uncomment the line and change it to read:

SSLCertificateChainFile /etc/pki/tls/certs/localhost.chain.crt

4. In the admin interface upload the server cert ("Upload this Server's SSL Certificate" on on Server -> SSL Settings).

5. Recreate the cert structure and reboot server:

c_rehash

reboot (again I suspect a HTTP daemon restart is all you need to do here)

< ----------------------------- >

That should be all there is to it. 

Also note that if you are connecting to this through a Cisco anchor controller (for example a Cisco 5508) then that too will need a publically signed SSL cert to avoid any security popups on devices - in which case you'll need to assign a publically routable address associated with a FQDN (fully qualified domain name) to the virtual interface. 

717
Views
0
Helpful
3
Replies
CreatePlease to create content