Captive Portal and secure login with wildcard domain certificate (solved)

sheepthief

Release 2.01

I'm not sure that this is anything to do with pfsense, but in case anyone else has come across this issue before…

When I first set up the login page for Captive Portal I used am internally generated certificate - that worked, but of course users got a security warning - that doesn't look very professional, so I needed to address that.

We've since purchased a wildcard domain certificate, say, *.our.domain, and I've configured Captive Portal for https with this certificate, private key, and intermediate certificate. The server name is, say, guest.our.domain, and I have DNS forwarding configured to point this at the interface that the Captive Portal is configured to use.

However, users still get a security warning for the login page, and this seems to be because the certificate (for *.our.domain) doesn't match the server name (guest.our.domain).

Is there anything that I can do about this, or do I have to purchase a certificate specifically for guest.our.domain?

eri--

You have thousand of guides on internet on how to setup wildcard certificates for use.
Please do not start this discussion here.

It has nothing to do with pfSense CP perse.

sheepthief

Thanks for the reply. Clearly my google-fu has deserted me as so far I've not found anything useful - I must be using the wrong keywords.

Incidentally, I've never found a definitive guide to setting up CP fully with proper certificates traceable to a root - if I ever get this working 100% I'll create a guide that contains all the steps. Hopefully /that/ would be within the scope of this forum.

sheepthief

By the way, I'm not actually certain where my problem lies - I'm only assuming that the security warning I'm getting is for the reason stated.

If anyone could confirm if they have CP fully functional with a wildcard cert that would be most useful.

Thanks

Reiner030

@sheepthief:

However, users still get a security warning for the login page, and this seems to be because the certificate (for *.our.domain) doesn't match the server name (guest.our.domain).
Is there anything that I can do about this, or do I have to purchase a certificate specifically for guest.our.domain?

You have set under System => General Setup right Hostname and Domain?
You have choosen under System => Advanced => Admin Access the right SSL Certificate ?
(perhaps captive Portal has different ssl certificate selection?)
and also good is to take a look what certificate your browser get really (if it matches name, is in the valid certificate time frame, …)

ohshinwifi

@ermal:

You have thousand of guides on internet on how to setup wildcard certificates for use.
Please do not start this discussion here.

It has nothing to do with pfSense CP perse.

Just want to add.

I'm not sure why you're so concerned that the OP's post is problematic for this forum.
Personally, I've tried many many times to research ways to make the wildcard work with a similar "more "robust""hotspot" hardware/router (MT).
With no luck.

I've been using MT hardware and been using they're forums and believe me, it's not exactly "gringo" friendly over there. lol.

I just set up PFsense the other day and love it! I'd love to change back to this package. But, it's not encouraging with a response like that. Really, I may not be the most patient in finding solutions on google. So, a forum is the natural source to understand and resolve.

Surely don't mean to be dissin you. Just looking for solutions as is the OP.
If you might have a suggestion, it would be appreciated and would hope to reciprocate in the future.
;D

Reiner030

Hi,

@ohshinwifi:

@ermal:

You have thousand of guides on internet on how to setup wildcard certificates for use.
Please do not start this discussion here.

It has nothing to do with pfSense CP perse.

Just want to add.

I'm not sure why you're so concerned that the OP's post is problematic for this forum.
Personally, I've tried many many times to research ways to make the wildcard work with a similar "more "robust""hotspot" hardware/router (MT).
With no luck.

Perhaps there are thousands of "HowTos" … but they often miss some important things...

I find this guide very helpful:
OpenSSL Command-Line HOWTO http://www.madboa.com/geek/openssl/

But even this miss the question howto generate Certificates which german umlauts or
other special chars in french, spanisch, portuguese for example. Problem: the chars
exists in ASCII but are not accepted/printed correctly in certificates :(

I searched last year a longer time to find the solution (ok, the manual is read last ;)) and
found the "workaround" in using UTF-8: http://www.openssl.org/docs/apps/req.html
-utf8
this option causes field values to be interpreted as UTF8 strings, by default they are interpreted as ASCII.
This means that the field values, whether prompted from a terminal or obtained from a configuration file,
must be valid UTF8 strings.

Then its also very difficult to find setup howtos for MultiDomain (and Multi-Level Wildcarts)…
There are 3 solutions:

the uglest: http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_
the better one: http://wiki.das-online.org/howtos/linux/security/openssl#multible_dns_hostnames (german, but configuration is clear)
in my opinion the best one: http://www.crsr.net/Notes/Apache-HTTPS-virtual-host.html

This is also a big difference between for instance Verisign / Thawte and Comodo and other registrars.
The expensive registrars give you "*.yourdomain.com", the cheaper ones give you "yourdomain.com, *.yourdomain.com" ( the direct SLD name is important)

Bests

ohshinwifi

Nice work!
You've done a lot.

It just shouldn't be that difficult… don't you agree?

Getting a wildcard cert. was my last project to get everything buttoned up.
I'm taking a break... untill tomorrow. ;)

Reiner030

@ohshinwifi:

Nice work!
You've done a lot.

It just shouldn't be that difficult… don't you agree?

Getting a wildcard cert. was my last project to get everything buttoned up.
I'm taking a break... untill tomorrow. ;)

I administrate "normally" live servers so it's daily business :)

yes, it's easy if you know how to do it right.

I love it go set per project/company an own openssl.cnf which I refer with parameter -config openssl.cnf in my calls and wrote all needed informations there for future "replay".
Important: change default keysize from 1024 to minimum 2048 ;)

http://support.godaddy.com/help/article/5619/why-does-my-csr-need-to-be-2048-bit-length

( I knew it from another registrar - but got only german email )

sheepthief

Thanks for all the replies, and particular kudos to Reiner030 - that gives me some reading to plough through this afternoon!

I actually have it working now, at least with IE and Firefox, but Opera and Safari are still complaining. I'll see what I can find within the links provided and report back as soon as I can.

sheepthief

Ok, I have a theory, as yet not properly tested, but it seems that CP may be involved in the problem.

Currently IE and Firefox (default settings) show no warnings, and say that the login page is secure.

Opera, Safari, and Firefox (tweaked) show certificate warnings.

If I log in via CP, then try accessing https://guest.our.domain:8001 then all browsers are fine - none of them show warnings. This suggests that CP is blocking something that Opera and Safari (and the tweaked FF) need in order to verify the certificate.

What's the tweak for Firefox you ask? Tools > options > advanced > encryption > validation > when an OCSP server connection fails treat the certificate as invalid.

So I think that the browsers are attempting to validate the certificate against revocation lists, but CP is blocking that, so IE and Firefox give up and just carry on (dodgy!), but Safari and Opera take the safer approach of stating that something's not quite right.

If I'm right then I just need to find out where the browsers are going to try to perform this validation, and add the domain to the "allowed hostnames" section of CP.

sheepthief

Success!

Ok, I should be more cautious, and do more comprehensive testing on more than one of my pfsense systems, but it's looking good.

Thanks for all the comments and suggstions folks. Even when suggestions turn out to be blind alleys they can often leads to other trains of thought and other interesting information.

To sum up there were two issues, as follows -

1. Initial problems were down to me having the login page as a sub-subdomain of the wildcard domain. Wildcard certificates usually apply only to a single subdomain, eg if you have *.my.domain then it's valid for test.my.domain but not my.domain or welcome.to.my.domain. That was my initial error, and a pretty basic one. But hey, learn as you go along…

2. The more interesting problem I encountered after fixing item 1, was that at the login page Opera and Safari threw up certificate warnings, whereas Firefox and IE didn't. It's just as well I tested Safari, as a large number of folk who connect to this system are Apple users. Anyway, the suspicions I noted above proved to be correct - CP was blocking browsers attempts to check certificate revocation lists. IE and Firefox ignored the timeout, but Opera and Safari are more picky. The solution was easy - we purchased our wildcard certificate from Globalsign, so I just stuck globalsign.com in the "allowed hostnames" section of the CP configuration.... and now I get no more certificate warnings!

What a relief!

Thanks again everyone.

Hats off to the programmers of pfsense - it's an excellent piece of kit. The only issues I've had with it (and I have a pretty complex setup), have been down to my own lack of understanding.

Reiner030

@sheepthief:

Success!

1. Initial problems were down to me having the login page as a sub-subdomain of the wildcard domain.

2. The more interesting problem I encountered after fixing item 1, was that at the login page Opera and Safari threw up certificate warnings, whereas Firefox and IE didn't.

;) than its fine.

=> yes, thats a problem. I don't know if an "official" certificate registrar ever offers such multilevel wildcard domains (ok, CaCert.org would but that registrar ist maximum only implemented in Firefox as I know)
for complete "documentation": that is the CRL URL defined in certificates.
For instance Google:
URI: http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl

mmh, when I tried to get cert and ospf uri per request:

$ echo -n | openssl s_client -connect www.google.com:443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -subject -issuer -ocspid -ocsp_uri
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer= /C=US/O=Google Inc/CN=Google Internet Authority

there is no URL ^^… seems that OCSP ist an additionional CRL to make it more "secure" (looking ^^).

ok, other site as example... here it works:
$ echo -n | openssl s_client -connect www.amazon.de:443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -subject -issuer -ocspid -ocsp_uri
subject= /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=www.amazon.de
issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa 10/CN=VeriSign Class 3 Secure Server CA - G3
http://ocsp.verisign.com

ok, Verisign, you pay much more than at other registrars… so you also should got more out ;)

CRL than this way:
$ echo -n | openssl s_client -connect www.google.com:443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -text | grep -i crl
X509v3 CRL Distribution Points:
URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl