Security

Reply
Super Contributor I
Posts: 293
Registered: ‎02-07-2013

Certificate chains in Captive portal

Hi,

I've uploaded a new cert to our controllers for use when https'ing to them or for use in our captive portal setup. Our cert has two intermediate CAs and a root CA. I've uploaded all 3 of them and a pkcs12 file cointaining the CN. The problem is that if a client device doesn't know about the root and intermediate CAs they'll get a warning that the cert ( in this case aruba2.york.ac.uk) cannot be verified. I would have thought that having uploaded all the CAs to the controller, a connbecti g client would see the CN and all the CAs. 

below are snapshots of the cert config page and the general config page showing where we use the certs

Rgds

Alex

 

aruba2-certs.png

 

aruba2-cert-usage.png

MVP
Posts: 562
Registered: ‎11-28-2011

Re: Certificate chains in Captive portal

What I tend to do (which almost always works), is combine the server cert with any applicable intermediates and the root in one file. Then upload that combined file as the server cert and implement it on the captive portal function.

 

In short, using notepad++ or similar, copy the text out of each cert, and paste it back into a combination file. Server cert first, then intermediates, then CA.

 

Try that?

Kudos appreciated, but I'm not hunting! (ACMX 104)
Aruba
Posts: 1,368
Registered: ‎12-12-2011

Re: Certificate chains in Captive portal

If the client does not know about the CA or intermediate, then they will never verify it.  They can simply tap continue to move forward.  Everything else should be ok.

Seth R. Fiermonti
Consulting Systems Engineer - ACCX, ACDX, ACMX
Email: seth@hpe.com
-----
If you found my post helpful, please give kudos
pto
Contributor I
Posts: 21
Registered: ‎05-02-2013

Re: Certificate chains in Captive portal

Validating a Server certificate is a local \ ocsp procedure. If all clients are in the same domain they sould have the Root CA and be able to validate the Certificate. If they dont, get a global one. geo or godaddy... or something,

 

if this portal is for guests the guests needs the root \ intermediat CA localy to validate the CA. you need a public one. go for Geo or some other huge PKi infrastructure deployed on most devices.

 

Just PM me. I can assist.

 

Reg,

PoTski

MVP
Posts: 562
Registered: ‎11-28-2011

Re: Certificate chains in Captive portal

Fair point regarding root trust needing to be there on the client in the first place. I was assuming alexsuoy would likely have known this and been using something from a well-known signer. I suspected this was a question about the cert being presented to the client in totallity, rather than in part.

 

OCSP might well be relevant, but that's partly browser dependant, and alexsuoy didn't mention a browser-specific problem?

 

alexsuoy, are you using a specific signer for the certs you're using? Who?

Kudos appreciated, but I'm not hunting! (ACMX 104)
pto
Contributor I
Posts: 21
Registered: ‎05-02-2013

Re: Certificate chains in Captive portal

its clear that he dont grasp how the feature works. Alex: just get yourself a SSL from a hughe provider. Deployed on mobile devices as well. Geotrust is good. You dont need to upload the root or intermidiate CAs. just the SSL sertificate. The client will handle the rest.
Super Contributor I
Posts: 293
Registered: ‎02-07-2013

Re: Certificate chains in Captive portal

Hmmm.

Certificate chain is from a reputable supplier. Root is from AddTrustExternalRoot CA which is fairly well known, although I guess that perhaps the Intermediate 

 

Back in the day when I offloaded SSL functionality onto a Brocade ServerIron load balancer, I used to concatenate the CN and any intermediate and root certs into a single file before uploading the cert onto the load balancer.  This ensures that whatever client I used  validated the cert  because the whole chain was there. Simple test was to just upload the CN cert, pick a browser that didn't know about the root authority and the site wouldn't be verified.  Replace the cert file with one containing root and intermediate CAs and  browser validates it successfully.

 

The web interface on the controller allows you to perform certificate management  including uploading root and intermediate CAs . I guess I wrongly assumed that if the controller will allow you to upload CAs then perhaps it would use them along with the the CN cert.

 

Next step is to replace the CA only file with one containing the full CA tree and see if that makes any difference... as suggested earlier.

 

 

MVP
Posts: 562
Registered: ‎11-28-2011

Re: Certificate chains in Captive portal

Yeah, Alex, I suggest you try what I mentioned as you say.

 

My gut tells me it's likely although the client trusts the CA (as you're using something "proper"), it's likely the client doesn't trust the intermediate used for your cert.

 

Seen this lots of times. As you say, combine the whole chain and upload it as a server cert, and re-test.

 

If you still get the issue, tell us what browser/device/os you're testing with?

 

Cheers.

Kudos appreciated, but I'm not hunting! (ACMX 104)
pto
Contributor I
Posts: 21
Registered: ‎05-02-2013

Re: Certificate chains in Captive portal

Hi, I think your statement is false. This would make for an awesome MITM box. :) Its the clients job to validate the chain. You can test it by uploading a SSL from your domain and validate it with your root. Regards, Peet
Search Airheads
Showing results for 
Search instead for 
Did you mean: