Captive Portal with Wildcard SSL certificate

Home Page Forums Network Management ZeroShell Captive Portal with Wildcard SSL certificate

This topic contains 12 replies, has 0 voices, and was last updated by  tphipps 1 year, 10 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #41035

    tphipps
    Member

    It seems that Captive Portal doesn’t like working with wildcard SSL certificates (eg. certificates containing a wildcard component as *.domain.com). With 1.0beta8, I can import such a certificate via the Captive Portal Authentication page, and it shows up as “OK”, I can even activate the Web Login Authentication Server.

    Problem is that if I turn on “Use CN to redirect”, which I need to turn on in order to use the certificate, the target host of the redirect is hardwired to the CN on the certificate, in this case the actual wildcard itself (https://*.domain.com in this example). Of course, this isn’t a valid host portion of a URI and the redirect fails.

    The only way I have found to work around this is to comment out the code in /root/kerbynet.cgi/scripts/cp_auth_start that updates the cp_as-httpd file with the CN of the certificate, and then to hardcode the appropriate hostname directly into /var/register/system/cp/Auth/cp_as-httpd

    This works fine for me, but it is a real hack. It would be much preferable if ZeroShell allowed the specification of an alternate CN for the redirect. Either it should allow this always (and not rely on what’s in the certificate), or maybe only when it detects a wildcard in the certificate.

    Any comments or thoughts about this? Any reason it would be a bad ideaa? Wildcard certs are incredibly useful when managing a myriad of servers that all have https needs…

    #46483

    imported_fulvio
    Participant

    I think make not sense what you would do. If you use a wildcard in the CN you shouldn’t use the flag “Use CN to redirect”.

    Why you don’t use the willcard in the “X509v3 Subject Alternative Name” extention?

    Regards
    Fulvio

    #46484

    tphipps
    Member

    Hi Fulvio, thanks for the reply.

    I have to turn on the “Use CN to redirect” flag as without this, the Captive Portal builds the redirect URL using the IP address of the interface on which it is running, and not a hostname. You can’t get a commercial SSL certificate for an IP address!

    As for the “Subject Alternative Name” attribute, this is also not feasable with a commercial SSL certificate. The whole idea of wildcard certificates is not having to know in advance the names of all the hosts that will be covered by the certificate. They simply need to share the same domain.

    If I were to create my own CA and self-sign the certificates, both of your approaches might certainly be possible. However, the wildcard certificate I am using is signed by a major Internet CA and is regcognized by all browsers without having to install a new root certificate, which in our captive portal deployment is very important. We don’t want users receiving certificate warnings or having to install new root certs…

    Toby.

    #46485

    imported_fulvio
    Participant

    Ok, it is clear for me your problem. I will try to add a new field in the captive portal authentication form that allows to specify the FQDN of the gateway.

    Regards
    Fulvio

    #46486

    tphipps
    Member

    Hi Fulvio,

    Any update on this? I’m having to patch my Zeroshell installation every time I reboot to avoid re-defaulting the hostname in the captive portal httpd.conf.

    Is this feature likely to happen soon? If not, can you suggest a way I can make my manual changes to /root/kerbynet.cgi/scripts/cp_auth_start and /var/register/system/cp/Auth/cp_as-httpd persist after a reboot?

    Thanks again.,

    #46487

    Click SSL
    Member

    I think that is a problem with your wildcard certificate because you have not requirement to do this that become easy whenever you set up your ssl certificate. contact wildcard ssl provider for exactly information.

    #46488

    tphipps
    Member

    It would be good if you read and understand the issue as presented above before advertising your certificate services on this forum! The issue is not with the certificate, but clearly with the way the ZeroShell console handles (handled?) wildcard certificates. It extracts (extracted?) the hostname from the certificate’s CN and attempts to use that as a hostname for redirect.

    I haven’t used ZeroShell for a long time now, and it’s possible that Fulvio has already patched this, hence my parenthesis above!

    @Click SSL wrote:

    I think that is a problem with your wildcard certificate because you have not requirement to do this that become easy whenever you set up your ssl certificate. contact wildcard ssl provider for exactly information.

    #46489

    mdeserventi
    Member

    Thera are news on wildcard certificate?

    #46490

    Davis
    Member

    @mdeserventi wrote:

    Thera are news on wildcard certificate?

    you can find news on wildcard ssl here https://www.sslmatrix.com/sslcertificates/wildcard-certificates

    #46491

    mdeserventi
    Member

    Sorry but i’m searching info to zeroshell certificate wildcard and not generic wildcard certificate. This post speak about zeroshell wildcard certificate problems ad i have requested info on this specific topic.

    Regards

    #46492

    kostis
    Member

    I just registered to this forum to say thank you to tphipps for his workaround and give a solution for keeping these changes after reboot:

    Comment out the code in /root/kerbynet.cgi/scripts/cp_auth_start that updates the cp_as-httpd file with the CN of the certificate like so:

        render "$TEMPLATE/$HTTPCONF" | sed "s/%{SERVER_ADDR}/$CN/g" #> /var/register/system/cp/Auth/cp_as-httpd
    else
    render "$TEMPLATE/$HTTPCONF" #> /var/register/system/cp/Auth/cp_as-httpd
    fi
    else
    render "$TEMPLATE/$HTTPCONF" #> /var/register/system/cp/Auth/cp_as-httpd

    and then hardcode the appropriate hostname directly into /var/register/system/cp/Auth/cp_as-httpd like so:

    RewriteRule ^.*$ https://captiveportal.example.com:12081/cgi-bin/zscp?Section=CPAuth&Action=Show&${filter:%{QUERY_STRING}} [L]

    instead of:

    RewriteRule ^.*$ https://*.example.com:12081/cgi-bin/zscp?Section=CPAuth&Action=Show&${filter:%{QUERY_STRING}} [L]

    Now, the only system folders that keep changes after reboot are /Database and /DB. Therefore, you can copy the modified files there:

    mkdir /Database/Scripts
    cp /root/kerbynet.cgi/scripts/cp_auth_start /Database/Scripts/
    cp /var/register/system/cp/Auth/cp_as-httpd /Database/Scripts/

    and then copy them back automatically on system boot:
    at the `Web-GUI > Setup > Startup/Cron > Pre Boot` enter these commands:

    /bin/cp /Database/Scripts/cp_auth_start /root/kerbynet.cgi/scripts/
    /bin/cp /Database/Scripts/cp_as-httpd /var/register/system/cp/Auth/

    If you are running ZeroShell from a Live CD you might also find this useful: How to install ZeroShell on Hard Disk however just note that installing ZeroShell on an HDD doesn’t make changes persistent, it still runs live on RAM.

    There you go! Now the users will be redirected to “https://captiveportal.example.com:12081” instead of “https://*.example.com:12081”

    Regards,
    /kostis

    #46493

    Aldan
    Member

    Is Captive Portal can be activated to also protect a VLAN 802.1Q instead that an entire network interface.?

    nutribulletrecipes.org
    http://en.wikipedia.org/wiki/Elance
    http://www.facebook.com/Elance

    #46494

    Steverussell
    Member

    SSL client certificates thereby vary from one to another depending on the type of clients that is going to use it. It is one of the best tools to authenticate your website and make sure that your users are provided the complete security and protection for the information they share. It depends on the user to choose the type of certificate for the website so that the security protocol can be installed and the sharing becomes secured.

    Cheap SSL Certificate

    #46495

    Gaskamp
    Member

    @Click SSL wrote:

    I think that is a problem with your wildcard certificate because you have not requirement to do this that become easy whenever you set up your ssl certificate. contact wildcard ssl provider for exactly information.

    How do you contact them?

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.