Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Results 1 to 4 of 4
  1. #1

    Lightbulb Doc's stupid simple instructions for installing (and maintaining!) a valid cert on a Linux EAP controller

    So about 7 months ago I posted instructions for hacking a valid certificate into a Windows EAP controller. Since then, TP-Link has done their customers a huge service by finally releasing the controller software for Linux. After being busy with other projects for a while, I decided it was time for me to jump ship to the Linux controller so I can literally pay half the cost I was paying for my Windows VPS (I'll probably ultimately migrate to an ODROID run locally, but this will do for now). Of course this made me recall my (mis)adventures in certificate land with the Windows controller. That brings me to the topic of today's post,

    Stupid simple instructions for installing (and maintaining!) a valid cert on a Linux EAP controller

    To start with, I'm going to recommend LetsEncrypt for your certificate needs -- but this should work with any valid cert from a major provider. Please note that if your system lives on an internal network and you can't temporarily forward port 80 to it, you'll have to procure the cert through other means, but these instructions will presume that you can run certbot and let it do its validation thing on port 80 one way or another.

    1. Get your cert. Make it into a full chain if it isn't already (i.e. concatenate your cert and any intermediate certs into one file); move (or link) it to the following path/file:
    /opt/tplink/EAPController/keystore/fullchain.pem

    and move or link the private key to
    /opt/tplink/EAPController/keystore/privkey.pem


    2. Copy/paste the following shell script into the /opt/tplink/EAPController/keystore path:
    Code:
    #!/bin/bash
    
    MYPATH="`dirname \"$0\"`"
    DATESTAMP=`date +"%Y%m%d_%H%M%S"`
     
    
    cd $MYPATH
    
    
    [ ! -f fullchain.pem ] && {
      echo "Your certificate/chain does not exist in this path! Please copy or link it into the following location and try again:"
      echo "  $MYPATH/fullchain.pem"
      echo ""
      echo "Exiting..."
      exit 1
    }
    [ ! -f privkey.pem ] && {
      echo "Your private key does not exist in this path! Please copy or link it into the following location and try again:"
      echo "  $MYPATH/privkey.pem"
      echo ""
      echo "Exiting..."
      exit 1
    }
    
    
    HOSTNAME=`openssl x509 -noout -subject -in fullchain.pem | grep -oP "CN=\K.*"`
    
    
    [ -f eap.keystore ] && {
      echo "Existing keystore found..."
      [ ! -f eap.keystore.ORIG ] && {
        echo "No .ORIG backup found, making backup..."
        cp "eap.keystore" "eap.keystore.ORIG"
      }
      echo "Moving current keystore to \"eap.keystore.$DATESTAMP\"..."
      mv "eap.keystore" "eap.keystore.$DATESTAMP"
    }
    
    
    echo "Packing fullchain.pem and privkey.pem into temporary PKCS#12 keystore..."
    openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -name eap -out keystore.p12 -password pass:myeapc
    echo "Importing temporary PKCS#12 keystore into final JKS keystore..."
    keytool -storetype jks -importkeystore -destkeypass tplink -deststorepass tplink -destkeystore eap.keystore -srckeystore keystore.p12 -srcstoretype PKCS12 -srcstorepass myeapc 2>&1 >/dev/null | grep -v "(Warning|proprietary)"
    echo "Removing temporary keystore..."
    rm -f keystore.p12
    tpeap stop
    tpeap start
    echo "Done! You should now be able to log into your controller via https://${HOSTNAME}:8043/"
    echo ""
    3. Save and exit, then make your script executable ( chmod +x scriptname )

    4. Run the script! It will do the dirty work of backing up your existing keystore (using a date-based extension), packing the regular .pem certificate and key into a PKCS#12 keystore (so the java keytool can understand it), and importing the PKCS#12 keystore into the JKS keystore that the controller software requires!

    If you have LetsEncrypt's certbot installed and can at least temporarily open up port 80 for it to do its validation thing, you can use it to obtain/renew your certificate, and link the fullchain.pem and privkey.pem files from certbot's certificate path (e.g. /etc/letsencrypt/live/example.com/) into the controller's keystore path. Then once you've obtained the cert via certbot, renewals are simply a matter of running certbot (e.g. certbot renew though you might need additional parameters depending on your configuration) and then running the script I provided!

    If you have any questions or issues, please post here and I'll try to help as best I can
    Last edited by DocJones; 11-03-2017 at 22:10. Reason: formatting shenanigans

  2. #2
    A full run of my script, which I called mkjks.sh, goes as follows (I run as root because the keystore path is by default only writable by root):

    Code:
    root@eapc:/opt/tplink/EAPController/keystore # ./mkjks.sh 
    Existing keystore found...
    Moving current keystore to "eap.keystore.20171103_181221"...
    Packing fullchain.pem and privkey.pem into temporary PKCS#12 keystore...
    Importing temporary PKCS#12 keystore into final JKS keystore...
    Importing keystore keystore.p12 to eap.keystore...
    Entry for alias eap successfully imported.
    Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
    
    Warning:
    The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore eap.keystore -destkeystore eap.keystore -deststoretype pkcs12".
    Removing temporary keystore...
    Stopping EAP Controller ...
    Stop successfully.
    Starting EAP Controller ....................................
    Start successfully.
    You can browse URL http://127.0.0.1:8088 for more.
    Done! You should now be able to log into your controller via https://eapc.example.com:8043/
    
    root@eapc:/opt/tplink/EAPController/keystore #
    (of course it shows my domain instead of "example.com"!)

    I wish I knew a meaningful way to suppress the JKS warning toward the end, but there's no way to do so (that I'm aware of) without potentially suppressing useful output (such as actual failure messages). Since the controller software expects it in JKS format, it barfs if you try to obey the warning and migrate your keystore file to the other format :P
    Last edited by DocJones; 11-03-2017 at 22:20.

  3. #3
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,127
    Very helpful, thanks for sharing!

  4. #4
    Very nice post.Thanks for the info.


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Copyright 1996-2017 TP-LINK Technologies Co., Ltd. All rights reserved.