How do I run the token in Debug mode?

« Back to Table of Contents

You've downloaded your two-factor authentications server and set it up per the installation instructions, but when you go to create a WiKID domain on the software token, you get "Could not obtain configuration for:  xxxxxxxxxx",  or "Could not connect to servercode" or some other error message.

Typically, this is a networking issue.  The token either can't reach the server or the server can't respond correctly.  You can troubleshoot issues by running the token in debug mode.  First on the server, re-run 'wikidctl setup' on the server and verify each network setting.  If that doesn't work, run the token in debug mode:

Here's what the file looks like:

You can also find it and copy it on your computer.  The domainSuffix is used to change the default DNS.  The default is to use UsIpBeforeDns tells the token to check to see if the domain is a zero-padded ip address before checking for a dns entry.  Debug=true turns on debug mode.

Now, run the software token client from the command line:

$ java -jar jWiKID.jar

This is what the output from the software token should look like for adding a new domain:

Sending 178 bytes of post data from pullConfig
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
wComms.connectInternal(): connecting to
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1 HTTP/1.1
Wrote 178 bytes.
Reading response iteratively ...
Returning data ... (296 bytes)
Read 296 bytes from the server
Reading 128 of ciphertext.
Reading 160 of server pub key data.
Recieved and Parsed Domain Configuration
name:Token client test

The token first tries http://333.344.445.555, which doesn't exist, so it then tries, which succeeds. The token gets the domain configuration information such as the registered URL and minium PIN and the user is asked to set their PIN.

Making connection to server.
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
wComms.connectInternal(): connecting to
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1 HTTP/1.1
Wrote 128 bytes.
Reading response iteratively ...
Returning data ... (272 bytes)
Recieved 256 bytes from server.
regcode length: 19
public key length: 160
Offline key size: 160

The PIN is encrypted and sent to the server. The server responds with the registration code, which is a 19 digit number. The number is hashed by the server's public key (to prevent a MITM attack during this process) and presented to the user as an 8 digit alphanumeric.

If you see an issue during this process, think about where it is occurring? Can the token write the WiKIDToken.wkd file (which has the public/private keys and domain information) to the file system? Can the token reach the server at http://333.344.445.555 or a DNS entry such as Does the DNS resolve? Do you see an attempt to connect to the WiKID Server in the WiKIDAdmin logs?

Ever since deploying WiKID, we  have  secured our Production systems from unauthorized access and maintained PCI compliance