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

    Lightbulb Hacking a valid cert into the EAP controller software

    So let's start by saying I hate invalid certificate errors. I've worn many hats: DevOps, IT Support, Customer Support, Web Designer, and more; each and every one screams "FIX IT" when I see one of these errors. Naturally, when I got my new access points (yes I use my EAP245 for my home), I was dismayed to see the invalid certificate error on the management page.

    Well I have my own domain name that I use for my home network devices and have used it to put valid certs on them (a pfSense router, an OMV file server, and a couple other gadgets), and thought to myself, "why can't I have a valid certificate on the EAP controller?"

    After many hours of poking around with much trial and error, I successfully managed to get the green padlock indicating a valid certificate!

    Name:  tplink-secure.png
Views: 0
Size:  19.3 KB

    DISCLAIMER: Proceed at your own risk! This worked for me, but I cannot guarantee that this process will not bork your EAP controller, invalidate your warranty, and/or kick an orphaned puppy. Please, think of the puppies.


    PREREQUISITES
    1. A domain name that you control DNS for
    2. A way to run the openssl command (either via a handy Linux/Mac box laying around, or an OpenSSL package for Windows on your controller or a handy Windows box)
    3. Full access to your EAP controller box
    4. Depending on your cert provider, an HTTP host you can use for verification

    PREPARING
    1. Create a subdomain for your controller under your desired domain name, e.g. "eap.example.com"
      • If your cert provider requires HTTP verification (e.g. LetsEncrypt), start by pointing this at an HTTP host you have access to, with a very low TTL

    PROCESS
    1. Shut down the EAP Controller software
    2. Make a copy of your current keystore (EAP Controller\keystore\eap.keystore) for safekeeping
    3. Generate a private key and CSR:

      openssl req -out MYSITE.csr -new -newkey rsa:4096 -nodes -keyout MYSITE.key

    4. Submit your CSR and get the cert from the CA
      • If your CA uses HTTP verification, once the process is complete change your DNS entry to point to your EAP controller's IP address
    5. Combine your cert and private key into a PKCS#12 key:

      openssl pkcs12 -export -in MYSITE.crt -inkey MYSITE.key -name eap -out MYSITE.p12
      • it is important that the "name" parameter is "eap"!
      • use an easy-to-remember password, you'll need it a few steps later (then it will be irrelevant)
    6. Make a copy of your current keystore (EAP Controller\keystore\eap.keystore) for safekeeping (you already did that right?)
    7. Delete the eap.keystore file in EAP Controller\keystore
    8. Import your PKCS#12 key into a new keystore:

      keytool -importkeystore -deststorepass tplink -destkeystore eap.keystore -srckeystore MYSITE.p12 -srcstoretype PKCS12
      • enter the password you specified in step 5 when prompted
    9. Restart the EAP Controller software!
    When it starts and loads the page, you should still see a certificate error; this is because it loads to https://127.0.0.1 which is never a valid hostname. If you browse to the hostname you created, e.g. https://eap.example.com:8043/ (don't forget the port number) you should now see the valid certificate!
    Last edited by DocJones; 04-17-2017 at 15:32.

  2. #2
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,135
    Very helpful, thanks! TP-Link admin should move it into the Knowledge Base for reference.

  3. #3

    No longer working...

    Hi there, I just followed your steps to the letter and the EAP controller fails to load with the new key store.

    I am using the 2.4.7 portal and this is the error in the server log. Which version were you successful with in getting this to run?

    Any help would be appreciated. It is a real shame TP-Link on an SOHO/Enterprise product don't make this easier to set up.

    2017-04-16 18:54:06 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring FrameworkServlet 'springMVC'
    2017-04-16 18:54:07 [main] [ERROR]-[EapJettyServer.java:38] - fail to start up jetty server .
    java.security.UnrecoverableKeyException: Cannot recover key
    at sun.security.provider.KeyProtector.recover(KeyProt ector.java:328)
    at sun.security.provider.JavaKeyStore.engineGetKey(Ja vaKeyStore.java:138)
    at sun.security.provider.JavaKeyStore$JKS.engineGetKe y(JavaKeyStore.java:55)
    at java.security.KeyStore.getKey(KeyStore.java:792)
    at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX 509KeyManagerImpl.java:131)
    at sun.security.ssl.KeyManagerFactoryImpl$SunX509.eng ineInit(KeyManagerFactoryImpl.java:68)
    at javax.net.ssl.KeyManagerFactory.init(KeyManagerFac tory.java:259)
    at org.eclipse.jetty.util.ssl.SslContextFactory.getKe yManagers(SslContextFactory.java:1080)
    at org.eclipse.jetty.util.ssl.SslContextFactory.doSta rt(SslContextFactory.java:291)
    at org.eclipse.jetty.util.component.AbstractLifeCycle .start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.ssl.SslSelectChannelConne ctor.doStart(SslSelectChannelConnector.java:612)
    at org.eclipse.jetty.util.component.AbstractLifeCycle .start(AbstractLifeCycle.java:64)
    at org.eclipse.jetty.server.Server.doStart(Server.jav a:293)
    at org.eclipse.jetty.util.component.AbstractLifeCycle .start(AbstractLifeCycle.java:64)
    at com.tp_link.eap.start.server.EapJettyServer.doStar t(EapJettyServer.java:36)
    at com.tp_link.eap.start.server.EapAbstractServer.sta rt(EapAbstractServer.java:68)
    at com.tp_link.eap.start.task.EapJettyStartUpTask.exe cute(EapJettyStartUpTask.java:15)
    at com.tp_link.eap.task.EapTaskEngine.runTasks(EapTas kEngine.java:13)
    at com.tp_link.eap.start.EapBootstrap.startup(EapBoot strap.java:360)
    at com.tp_link.eap.start.EapMain.main(EapMain.java:13 )
    2017-04-16 18:54:07 [main] [INFO]-[DbCompatibleServcie.java:96] - no need to compatible db.

    Quote Originally Posted by DocJones View Post
    Model :

    Hardware Version :

    Firmware Version :

    ISP : [/COLOR]

    So let's start by saying I hate invalid certificate errors. I've worn many hats: DevOps, IT Support, Customer Support, Web Designer, and more; each and every one screams "FIX IT" when I see one of these errors. Naturally, when I got my new access points (yes I use my EAP245 for my home), I was dismayed to see the invalid certificate error on the management page.

    Well I have my own domain name that I use for my home network devices and have used it to put valid certs on them (a pfSense router, an OMV file server, and a couple other gadgets), and thought to myself, "why can't I have a valid certificate on the EAP controller?"

    After many hours of poking around with much trial and error, I successfully managed to get the green padlock indicating a valid certificate!

    Attachment 4902

    DISCLAIMER: Proceed at your own risk! This worked for me, but I cannot guarantee that this process will not bork your EAP controller, invalidate your warranty, and/or kick an orphaned puppy. Please, think of the puppies.


    PREREQUISITES
    1. A domain name that you control DNS for
    2. A way to run the openssl command (either via a handy Linux/Mac box laying around, or an OpenSSL package for Windows on your controller or a handy Windows box)
    3. Full access to your EAP controller box
    4. Depending on your cert provider, an HTTP host you can use for verification

    PREPARING
    1. Create a subdomain for your controller under your desired domain name, e.g. "eap.example.com"
      • If your cert provider requires HTTP verification (e.g. LetsEncrypt), start by pointing this at an HTTP host you have access to, with a very low TTL

    PROCESS
    1. Shut down the EAP Controller software
    2. Make a copy of your current keystore (EAP Controller\keystore\eap.keystore) for safekeeping
    3. Generate a private key and CSR:

      openssl req -out MYSITE.csr -new -newkey rsa:4096 -nodes -keyout MYSITE.key

    4. Submit your CSR and get the cert from the CA
      • If your CA uses HTTP verification, once the process is complete change your DNS entry to point to your EAP controller's IP address
    5. Combine your cert and private key into a PKCS#12 key:

      openssl pkcs12 -export -in MYSITE.crt -inkey MYSITE.key -name eap -out MYSITE.p12
      • it is important that the "name" parameter is "eap"!
      • use an easy-to-remember password, you'll need it a few steps later (then it will be irrelevant)
    6. Make a copy of your current keystore (EAP Controller\keystore\eap.keystore) for safekeeping (you already did that right?)
    7. Delete the eap.keystore file in EAP Controller\keystore
    8. Import your PKCS#12 key into a new keystore:

      keytool -importkeystore -deststorepass tplink -destkeystore eap.keystore -srckeystore MYSITE.p12 -srcstoretype PKCS12
      • enter the password you specified in step 5 when prompted
    9. Restart the EAP Controller software!
    When it starts and loads the page, you should still see a certificate error; this is because it loads to https://127.0.0.1 which is never a valid hostname. If you browse to the hostname you created, e.g. https://eap.example.com:8043/ (don't forget the port number) you should now see the valid certificate!

  4. #4
    That's odd. Let's try some troubleshooting first.
    1. Open a command prompt and navigate to "C:\Program Files (x86)\TP-LINK\EAP Controller\keystore" (assuming the EAP controller software is installed in C:\Program Files (x86)\TP-LINK\EAP Controller)
    2. At the prompt, type ..\jre\bin\keytool.exe -list -v -keystore eap.keystore
    3. Enter tplink as the password when prompted
    Your output should look something like this:
    Code:
    Keystore type: JKS
    Keystore provider: SUN
    
    
    Your keystore contains 1 entry
    
    
    Alias name: eap
    Creation date: <DATE>
    Entry type: PrivateKeyEntry
    Certificate chain length: 2
    Certificate[1]:
    Owner: CN=<YOUR DOMAIN NAME>
    Issuer: CN=<CERT ISSUER>, O=<ISSUER ORG>, C=<ISSUER COUNTRY>
    Serial number: <CERT SERIAL NUMBER>
    Valid from: <FROM DATE> until: <TO DATE>
    Certificate fingerprints:
             MD5:  <16-OCTET FINGERPRINT>
             SHA1: <20-OCTET FINGERPRINT>
             SHA256: <32-OCTET FINGERPRINT>
             Signature algorithm name: <probably SHA256withRSA>
             Version: 3
    
    
    Extensions:
    (lots of stuff here that's not terribly important)
    The three important bits here are:
    1. "tplink" (all lower case) should be the password and that should successfully display the certificate information
    2. The certificate alias name should be "eap" (all lower case)
    3. The file should be "eap.keystore", directly in the "EAP Controller\keystore" path
    If any of these are not true, the controller software will definitely puke. If the file is just named wrong or in the wrong path, that should be easy enough to correct; if the password or alias are incorrect, you're probably best off re-rolling the keystore from scratch.

    Let me know how the troubleshooting goes!

  5. #5
    So from the top, and thanks for taking the time to reply also... :0)

    1) running that command with the password as 'tplink' nets me the following (and btw, where is the keystore password being set to tplink?)

    Alias name: eap
    Creation date: 16-Apr-2017
    Entry type: PrivateKeyEntry
    Certificate chain length: 3
    Certificate[1]:
    Owner: xxx, xxx
    Issuer: xxx, xxx, xxx, xxx
    Serial number: xxx
    Valid from: xxx until: xxx
    Certificate fingerprints:
    MD5: E3:E4:21:60:F6:E0:82:E4:35:47:B7D:78:5E:36:ED
    SHA1: 12:1D:E2:59:7B:79:F6:532:0B2:9A:CB:EF:20:02:AE1:C2:37
    SHA256: A3:18:9B:4F:50B:56:41:8F:CF:29:C1:1D56:7B:50:24:0A:4E:25:E0:46:B3:2E:2BC:52:FB:9C:6B:13
    Signature algorithm name: SHA256withRSA
    Version: 3


    Extensions:

    2) Alias name looks spot on.
    3) The file is in the keystore folder directly. The original is also there renamed to eap.keystore.orig

    A friend of mine also tried the exact same steps on his setup, getting exactly the same results. He is also on version 2.4.7 of the controller software.

    As mentioned before where is the java keystore password being set in the process, I am wondering whether this is to do with the issue?

    Phill

    Quote Originally Posted by DocJones View Post
    That's odd. Let's try some troubleshooting first.
    1. Open a command prompt and navigate to "C:\Program Files (x86)\TP-LINK\EAP Controller\keystore" (assuming the EAP controller software is installed in C:\Program Files (x86)\TP-LINK\EAP Controller)
    2. At the prompt, type ..\jre\bin\keytool.exe -list -v -keystore eap.keystore
    3. Enter tplink as the password when prompted
    Your output should look something like this:
    Code:
    Keystore type: JKS
    Keystore provider: SUN
    
    
    Your keystore contains 1 entry
    
    
    Alias name: eap
    Creation date: <DATE>
    Entry type: PrivateKeyEntry
    Certificate chain length: 2
    Certificate[1]:
    Owner: CN=<YOUR DOMAIN NAME>
    Issuer: CN=<CERT ISSUER>, O=<ISSUER ORG>, C=<ISSUER COUNTRY>
    Serial number: <CERT SERIAL NUMBER>
    Valid from: <FROM DATE> until: <TO DATE>
    Certificate fingerprints:
             MD5:  <16-OCTET FINGERPRINT>
             SHA1: <20-OCTET FINGERPRINT>
             SHA256: <32-OCTET FINGERPRINT>
             Signature algorithm name: <probably SHA256withRSA>
             Version: 3
    
    
    Extensions:
    (lots of stuff here that's not terribly important)
    The three important bits here are:
    1. "tplink" (all lower case) should be the password and that should successfully display the certificate information
    2. The certificate alias name should be "eap" (all lower case)
    3. The file should be "eap.keystore", directly in the "EAP Controller\keystore" path
    If any of these are not true, the controller software will definitely puke. If the file is just named wrong or in the wrong path, that should be easy enough to correct; if the password or alias are incorrect, you're probably best off re-rolling the keystore from scratch.

    Let me know how the troubleshooting goes!

  6. #6
    Ignore the question about the keystore password. I opened my eyes properly and read the command line ;0)

    That is working for sure, as when I enter another incorrect password to list out the keystore contents I get errors.

  7. #7
    Hmmm, I'll have to spin up a new controller instance and test the steps again, maybe I missed something (as I was largely documenting "after the fact").

    To clarify for others, the password is being set in the last command in my instructions via the -deststorepass tplink parameter

  8. #8
    So a quick update. Without regenerating anything I opened up the keystore in a Java based GUI. The tplink password worked. However when attempting to rename the key pair alias name and having to supply the same password again I got an error.

    Using the GUI tool I reimported the PK12 file, and double checked that tplink was indeed working for that specific key pair. Now loads and all is fine with the world... :0)

    Looking back through my command line history I definitely haven't fat fingered the password. Initial opening of the keystore did work with tplink as the password but manipulations on the key pair failed.

    Hope this extra information helps.

    Phill

  9. #9
    Might just be that the EAPC application has some tweaks to how it processes the cert that don't always play nice with a keytool-generated cert (since they expect it to only run with the provided cert), and that the GUI tool does something different (maybe doesn't add one of the extensions or something) that ends up with a more reliable cert.

    For others interested in doing this, perhaps if my commandline instructions don't work for you, try the GUI tool?


 

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.