12-12-2013 08:35 AM
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
12-12-2013 09:08 AM
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.
12-12-2013 09:09 AM
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.
Consulting Systems Engineer - ACCX, ACDX, ACMX
If you found my post helpful, please give kudos
12-12-2013 03:24 PM
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.
12-12-2013 10:43 PM
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?
12-13-2013 02:12 AM
12-13-2013 03:30 AM
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.
12-13-2013 04:34 AM
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?
12-13-2013 04:37 AM