- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-08-2013 05:02 AM
Hello,
We have a PA-3020 running PanOS 5.0.0 in L3 deployment. We have just one Private zone and one Public zone for the instance.
I have configured a Captive Portal policy on the Private zone gto ensure that all users that are not authenticated by User-ID (users who are not logged in the domain) have to authenticate beffore accessing resources. I have set a Captive Portal redirect policy web-form based, linked with LDAP settings.
It works fine, users are redirected to the web-form and they can login if they have a login/password.
Then we have tried to import a certificate on the PaloAlto device in order to avoid the warning message in the browser. We have tried to add the CA root certificate as well as the intermediate certificate. From the PaloALto menu, the chaining seems correct (see certificate_chain.jpg) but the warning is still there in the browser. When we look at the certificate sent by the PaloAlto to the browser, we can see that the chaining is not effective.
However, it works fine for the management access : the certificate chain is effective and the certificate is well trusted by the browser. Also it seems that it is only related to the Captive Portal feature.
You can also see the Captive Portal settings (captive_portal.jpg).
Kind Regards,
01-08-2013 09:42 AM
You may need to re-import the Captive Portal certificate (*.aiglon.ch) with the intermediate CA included in the chain. The firewall has the intermediate and it can "see" the full chain, but unless it is configured to send the intermediate with the CP certificate, it will assume the client has that intermediate and not send it.
The following document was written with two intermediate CAs in mind, but the principle is the same. You would create e hybrid certificate with *.aiglon.ch on top and "GlobalSign Organization Validation CA" below that. You don't need the root ("GlobalSign Root CA") because a client wouldn't trust a root that was sent to it anyway. Here's the doc:
How to Install a Chained Certificate Signed by a Public CA
Hope that helps!
Greg Wesson
01-08-2013 07:18 AM
Hi,
Could you add a screenshot of the displayed URL when you are reaching your captive Portal Authentication Webpage?
Thanks
Regards
-Nicolas
01-08-2013 08:40 AM
Hi Nicolas,
Thanks for your answer.
Here are three screenshots : One shows the url when accessing the Captive Portal, the others show the certificate details.
Regarsd
01-08-2013 09:42 AM
You may need to re-import the Captive Portal certificate (*.aiglon.ch) with the intermediate CA included in the chain. The firewall has the intermediate and it can "see" the full chain, but unless it is configured to send the intermediate with the CP certificate, it will assume the client has that intermediate and not send it.
The following document was written with two intermediate CAs in mind, but the principle is the same. You would create e hybrid certificate with *.aiglon.ch on top and "GlobalSign Organization Validation CA" below that. You don't need the root ("GlobalSign Root CA") because a client wouldn't trust a root that was sent to it anyway. Here's the doc:
How to Install a Chained Certificate Signed by a Public CA
Hope that helps!
Greg Wesson
01-08-2013 09:43 AM
IMHO we are looking at a browser/ client issue here.
Looks like you are using IE, the issuing CA 'Globalsign Organization Validation CA' needs to be trusted on your client.
Try to import the intermediate CA into the 'Trusted Root Certification Authorities' store on you windows client.
If the error disappears you can distribute the intermediate CA via GPO in your AD.
Thanks
01-08-2013 12:54 PM
It seems that 'Globalsign Organization Validation CA' is not present in windows Trusted Root certificate store.
Ulli and Greg's replies are both valid solutions.
-Nicolas
01-08-2013 08:39 PM
Greg's solution is actually the better on, it doesn't involve 'touching' all clients. Having the 'server' present his own and the intermediate CA allows the 'client' to confirm the authenticity of the server certificate with only having the root in his store.
Using openssl you can easily confirm that your imported cert on the PAN the it is working correctly
openssl s_client -CAfile <full path to root cert> -quiet -showcerts -connect <ip or fqdn of PAN>:6082
Thanks
Ulli
01-10-2013 02:28 AM
Hi guys,
Thanks for your help and advices but it still doesn't work.
I followed this guide and created a joint PEM with the two certs.
I could import this but I am not sure I understand the next part. Before importing that do I need to make a CSR that matches that cert so that I can import it and have the private key.
If I import without a private key then I obviously can’t use it to sign the captive portal.
I also have a PFX bundle, that contains all of the certs and also the private key – importing that works and I can assigned it to the management web interface and the captive portal.
As before the management web interface show no errors and works correctly but the captive portal doesn’t seem to present the intermediate certificate.
Regards,
01-10-2013 05:53 PM
Since you have the PFX, you can use openSSL to convert the PFX into separate files. Get the private key from that, then you can import the private key and the joint PEM file you created (no need for the CSR then).
08-10-2013 07:29 PM
What you do is merge the certificate and the CA into one cert and upload. Palo Alto will not join the chain together for you. You need to join the certificates yourself then upload. The Panorama will strip the second certificate, so you will need to upload locally. Took a bit of time but again, works nicely. So do something like....
cat mycert.crt myCA.crt > mycertchain.pem. Then upload that with the key. This works.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!