Security

last person joined: 10 hours ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Certificate chains in Captive portal

This thread has been viewed 21 times
  • 1.  Certificate chains in Captive portal

    Posted Dec 12, 2013 11:35 AM

    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



  • 2.  RE: Certificate chains in Captive portal

    Posted Dec 12, 2013 12:08 PM

    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?



  • 3.  RE: Certificate chains in Captive portal

    EMPLOYEE
    Posted Dec 12, 2013 12:10 PM

    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.



  • 4.  RE: Certificate chains in Captive portal

    Posted Dec 12, 2013 06: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.

     

    Reg,

    PoTski



  • 5.  RE: Certificate chains in Captive portal

    Posted Dec 13, 2013 01:44 AM

    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?



  • 6.  RE: Certificate chains in Captive portal

    Posted Dec 13, 2013 05:13 AM
    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.


  • 7.  RE: Certificate chains in Captive portal

    Posted Dec 13, 2013 06:31 AM

    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.

     

     



  • 8.  RE: Certificate chains in Captive portal

    Posted Dec 13, 2013 07:35 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?

     

    Cheers.



  • 9.  RE: Certificate chains in Captive portal

    Posted Dec 13, 2013 07:37 AM
    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