Captive Portal SSL Certificate?

[tjcarter]

Does anyone have a recommendation on where we can get an SSL certificate that works with the Captive Portal and will be fully trusted by the most commonly used browsers.  Or.. perhaps some guidance on how this situation is best tackled...  Our situation is as follows:

1) We want a certificate that will not generate an error of any sort when digested by the browser.

2) Our certificate needs to be issued to an IP address. We do not control the DNS server so we are unable to get the required reverse DNS entry implemented.

3) We tried a COMODO Certificate.  It worked in some browsers but on a fresh install of Windows 7 w/ IE 8 we get an certificate error.  If we download and install the COMODO root and intermediate certificates all is well.  COMODO support recommends that we install these on the PAN (PAN 2050 for us), but I do not see this as an option on the PAN.

4) Research and COMODO support recommended a unchained certificate but it seems they are no longer being offered.

Thanks in advance for any and all replies!

[pantac]

To install the root and intermediate certs you will need to open both in notepad. Paste all of the text from the intermedite certificate to the bottom of the root certificate. Then import this new certificate into the PAN device. This can be used for both Captive Portal and SSL-VPN certificates.

[tjcarter]

So there is a way!  One last question and I think I am home free.  Where should the combined certificate be imported?  Client OCSP Verfiy CA Certificate?  Trusted CA Certificate? or Client CA Certificate?

Thanks again for your help!

[nrice]

Under "Certificates on the "Device" tab:

[tjcarter]

The previous advice was to combine the required root and intermediate certificates.  Such a certificate will not load in the area you suggest since we have neither the required key or passphrase.

[nrice]

To clarify the earlier response from pantac - some certificate providers are using Intermediate certificates.  This means that your server certificate is signed by an intermediate certificate, and that intermediate certificate is signed by a root certificate.  This is a certificate in between the root certificate and your server certificate.  This intermediate certificate is not generally included in your browser so it needs to be served with the server certificate. 

Some Certificate authorities already bundle the intermediate certificate with your certificate.

But, when they do not, you'll need to get a copy of  the intermediate certificate first.

Then, you'll need to open the server certificate and the intermediate certificate in notepad, and paste all of the text from the intermediate certificate to the bottom of the server certificate.  Then import this new certificate into the certificate section labeled “SSL VPN/SSL Inbound Inspection/Captive Portal Certificate”

[Billy_G]

Hi, We had a similar issue with a Comodo cert. Have you resolved this as we have fixed this after having a problem with the cert and the warning in internet explorer.

Regards....

[tjcarter]

We are making progress but are still struggling to get things working just right.  The previous advise was very helpful and did work.  We can load both certificates and they are both propagated to the client browser without a problem.  Our latest challenge is that the COMODO root is not installed on some systems.  Specifically Window 7 PC's.

It seems Microsoft is not longer shipping certificates as part of their OS.  Instead they provide a service that takes a new root certificate and checks windows update to see if it has been certified by them.  Since we are blocking all traffic until a user is authenticated this transaction is blocked and a certificate error reported.

What it seems we need now is a policy to allow the transaction.  I have yet to dive into trying to craft one and have a few questions about it.  For example...  what interface would we apply this policy to.  At this stage we are talking with the L3 interface that only exists to provide the captive portal.  Do we need to flesh that out so that traffic can flow through it?  Or do we keep the policy on the transparent interface?

Any guidance would be most appreciated.

[skrall]

You need to create a rule from the inside zone to to the outside zone , Source user = unknown and then permit traffic either by application or by destination IP address. Many captive portals need to do this for App = DNS as well becasue the DNS server is often on the other side of the firewall. Hopefully we are able to identify the application. Put this rule near the top of  the list so it gets evaluated before any rules permitting known users or dropping unkniwn users.

Steve Krall

[Billy_G]

Hi,

We had to create a rule under "Captive Portal Rules" Below is what we have...

Name=Comodo Certificate Rule

Source Zone=Trusted Network

Destination Zone=Untrusted Network

Source Adress=Any

Destination Address=

216.191.247.139
216.191.247.227
217.118.26.135
65.55.21.250
69.58.183.143
85.13.204.99
91.209.196.174
149.5.128.174
91.199.212.174

Method=no-captive-portal

This needs to be at the top of the rules. This will allow any user requesting the captive portal to reach the comodo servers to authenticate the certificate.

Hope this helps as this is what we had to do, and it works like a charm.....

[tjcarter]

That is exactly what I was looking for!  Many thanks for laying it out so clearly.

[migration]

Hi nrice,

when and how we use "Client CA Certificate" ?

Thanks

[nrice]

Hi Iceman,

The  Device > Client CA Certificate  allows you to import one or more certificates to be used for authentication for an administrator or  SSL VPN login.  Once CA certs are imported, the Device> Client Certificate Profile allows you to choose a CA cert, which will become part of the profile attached to the admin or ssl vpn login.