Enhancing the security of your WAPT setup

By default, all WAPT packages are signed with your private key, which already provides a great level of security. However you can further improve the security of WAPT.

To fully secure your WAPT setup; you will want to do the following:

  • enable authenticated registration to filter who is authorized to register the device with the WAPT server;

  • enable https certificate verification on the agents and the console to ensure that the WAPT agents and the WAPT console are connecting to the correct WAPT server;

  • configure authentication against Active Directory to allow access to the WAPT console only to authorized WAPT admins;

  • enable Client-Side Certificate Authentication to only allow authenticated devices to access the WAPT server (Note: it is especially important if you want to expose your WAPT server to the outside in a DMZ);

  • if you are using the Enterprise version of WAPT and you operate a large fleet with multiple administrators, you may be interested in knowing how to properly configure and apply the ACLs.

Configuring the firewall on the WAPT Server

WAPT Server firewall configuration is essential and should be the first step towards achieving better security in WAPT.

As WAPT aims to be secure by design, only a minimal set of open ports is needed on the WAPT Server compared to other solutions.

You will find in the following documentation firewall tips to improve WAPT security.

Data-flow diagram of WAPT

Data-flow diagram of WAPT

As you can see, only ports 80 and 443 must be opened for incoming connections as the WAPT frameworks works with websockets initiated by the WAPT agents.

Configuring the firewall for WAPT Server on Debian Linux

By default on Debian Linux, no firewall rule applies.

  • disable ufw and install firewalld instead:

    ufw disable
    apt update
    apt -y install firewalld
  • simply apply this firewalld configuration:

    systemctl start firewalld
    systemctl enable firewalld
    firewall-cmd --zone=public --add-port=80/tcp --permanent
    firewall-cmd --zone=public --add-port=443/tcp --permanent
    systemctl restart firewalld

Configuring the firewall for WAPT Server on CentOS

  • simply apply this firewalld configuration:

    systemctl start firewalld
    systemctl enable firewalld
    firewall-cmd --zone=public --add-port=80/tcp --permanent
    firewall-cmd --zone=public --add-port=443/tcp --permanent
    systemctl restart firewalld

Configuring kerberos authentication


  • without kerberos authentication, you have to either trust initial registration or enter a password for each workstation on initial registration;

  • for more information, visit the documentation on registering a machine with the WAPT Server and signing inventory updates;

  • the kerberos authentication will be used only when registering the device;

Installing the kerberos components and configuring krb5.conf file

apt install krb5-user msktutil libnginx-mod-http-auth-spnego

yum install krb5-workstation msktutil nginx-mod-http-auth-spnego


The feature is not available with a WAPT Windows server

Modify the /etc/krb5.conf file and replace all the content with the following 4 lines replacing MYDOMAIN.LAN with your Active Directory domain name (i.e. <MYDOMAIN.LAN>).


default_realm must be written with ALL CAPS!!

  default_realm = MYDOMAIN.LAN
  dns_lookup_kdc = true

Retrieving a service keytab. Use the :command:`kinit and klist. You can use an Administrator account or any other account with the delegated right to join a computer to the domain in the proper destination container (by default CN=Computers).

In the shell transcript below, commands are in black and returned text is commented in light gray:

sudo kinit administrator
## Password for administrator@MYDOMAIN.LAN:
## Warning: Your password will expire in 277 days on lun. 17 sept. 2018 10:51:21 CEST
sudo klist
## Ticket cache: FILE:/tmp/krb5cc_0
## Default principal: administrator@MYDOMAIN.LAN
## Valid starting       Expires              Service principal
## 01/12/2017 16:49:31  02/12/2017 02:49:31  krbtgt/MYDOMAIN.LAN@MYDOMAIN.LAN
## renew until 02/12/2017 16:49:27

If the authentication request is successful, you can then create your HTTP Keytab with the msktutil command.

Be sure to modify the <DOMAIN_CONTROLER> string with the name of your domain controller (eg: srvads.mydomain.lan).

sudo msktutil --server DOMAIN_CONTROLER --precreate --host $(hostname) -b cn=computers --service HTTP --description "host account for wapt server" --enctypes 24 -N
sudo msktutil --server DOMAIN_CONTROLER --auto-update --keytab /etc/nginx/http-krb5.keytab --host $(hostname) -N


Be sure to have properly configured your WAPT Server hostname before running these commands;

In order to double check your hostname, you can run echo $(hostname) and it must return the name that will be used by WAPT agent running on client workstations.

  • apply the proper access rights to the http-krb5.keytab file:

    sudo chmod 640 /etc/nginx/http-krb5.keytab
    sudo chown root:www-data /etc/nginx/http-krb5.keytab
    sudo chown root:nginx /etc/nginx/http-krb5.keytab
    sudo chmod 640 /etc/nginx/http-krb5.keytab

Post-configuring kerberos for the WAPT server

You can now use post-configuration script to configure the WAPT Server to use kerberos.

The post-configuration script will configure Nginx and the WAPT Server to use kerberos authentication.


This post-configuration script must be run as root.

/opt/wapt/waptserver/scripts/postconf.sh --force-https

Kerberos authentication will now be configured.

Special use cases

My WAPT server does not have access to a writeable Active Directory

  • connect to your Active Directory (Not a RODC);

  • create a computer account srvwapt;

  • add a SPN on the srvwapt$ account;

    setspn -A HTTP/srvwapt.mydomain.lan srvwapt
  • create a keytab for this WAPT server:

    ktpass -out C:\http-krb5.keytab -princ HTTP/srvwapt.mydomain.lan@MYDOMAIN.LAN rndpass -minpass 64 -crypto all -pType KRB5_NT_PRINCIPAL /mapuser srvwapt$@MYDOMAIN.LAN
    Reset SRVWAPT$'s password [y/n]?  y


    If the address of your WAPT server is different from your active directory domain, replace HTTP/srvwapt.mydomain.lan@MYDOMAIN.LAN with HTTP/srvwapt.othername.com@MYDOMAIN.LAN.

  • transfer this file to /etc/nginx/ (with winscp for example);

  • apply the proper access rights to the http-krb5.keytab file:

    sudo chmod 640 /etc/nginx/http-krb5.keytab
    sudo chown root:www-data /etc/nginx/http-krb5.keytab
    sudo chown root:nginx /etc/nginx/http-krb5.keytab
    sudo chmod 640 /etc/nginx/http-krb5.keytab

WAPT agent only have access to a RODC domain controller

  • for RODC, add the srvwapt account to the allowed password group for replication;

  • remember to preload the password of the WAPT server with the different RODC servers;

Preload Password srvwapt account

You have multiple Active Directory domains with or without relationships

If you have multiple Active Directory domains, you must create one keytab per domain by following the procedure above, ex:

  • http-krb5-domain1.local.keytab;

  • http-krb5-domain2.local.keytab;

  • http-krb5-domain3.local.keytab;

You will then have to merge all these keytabs into a unique keytab:

read_kt http-krb5-domain1.local.keytab
read_kt http-krb5-domain2.local.keytab
read_kt http-krb5-domain3.local.keytab
write_kt http-krb5.keytab

Debug problems with the kerberos


  • the server address cannot be an IP, Kerberos works well only with DNS;

  • in your test, the url used must be exactly the same address as the one indicated in C:\Program Files (x86)\wapt\wapt-get.ini

Did you restart nginx correctly?

systemctl restart nginx

Check the permissions of the http-krb5.keytab file

[root@srvwapt.mydomain.lan]# ls -l /etc/nginx/http-krb5.keytab
-rw-r----- 1 root www-data 921 janv.  4 16:20 /etc/nginx/http-krb5.keytab

Is kerberos mode active on my agent?

On the windows machine:

  • check in your C:\Program Files (x86)\wapt\wapt-get.ini that the use_kerberos value is True:

  • if you change the value, don’t forget to restart the wapt service:

    net stop waptservice
    net start waptservice

Is Kerberos mode active on my server?

On the linux machine:

  • check in your /opt/wapt/conf/waptserver.ini that the use_kerberos value is True:

  • check in your /etc/nginx/sites-enabled/wapt.conf that this configuration is present:

    location /add_host_kerberos {
      auth_gss on;
      auth_gss_keytab /etc/nginx/http-krb5.keytab;
  • if one of the two configurations is not present, restart the post-configuration and activate kerberos;

Checking that the keytab file contains the correct url

[root@srvwapt.mydomaine.lan]# KRB5_KTNAME=/etc/nginx/http-krb5.keytab klist -k
Keytab name: FILE:/etc/nginx/http-krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 HTTP/srvwapt.ad.mydomain.lan@AD.MYDOMAIN.LAN

Trying to register the host using a system account

To switch to a system account you must use the psexe tool from Microsoft: https://download.sysinternals.com/files/PSTools.zip

  • in cmd as an administrator:

    C:\Users\\xxxxxx\\Downloads\\PSTools\\psexec.exe -accepteula -s -i cmd
  • in the new cmd window, check that you are identified as System:

  • run register:

    wapt-get register

Trying an authentication with the keytab from your WAPT server

  • on the linux machine:

    [root@srvwapt.ad.tranq ~]# ktutil
    ktutil:  read_kt /etc/nginx/http-krb5.keytab
    ktutil:  list
    slot KVNO Principal
    ---- ---- ---------------------------------------------------------------------
       1    3                  srvwapt$@AD.TRANQUIL.IT
       2    3                  srvwapt$@AD.TRANQUIL.IT
       3    3                  srvwapt$@AD.TRANQUIL.IT
       4    3                  SRVWAPT$@AD.TRANQUIL.IT
       5    3                  SRVWAPT$@AD.TRANQUIL.IT
       6    3                  SRVWAPT$@AD.TRANQUIL.IT
       7    3              host/srvwapt@AD.TRANQUIL.IT
       8    3              host/srvwapt@AD.TRANQUIL.IT
       9    3              host/srvwapt@AD.TRANQUIL.IT
      10    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
      11    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
      12    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
    ktutil:  quit
    [root@srvwapt.ad.tranq ~]# kinit -k -t /etc/nginx/http-krb5.keytab srvwapt\$@AD.TRANQUIL.IT
    [root@srvwapt.ad.tranq ~]# klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: srvwapt$@AD.TRANQUIL.IT
    Valid starting       Expires              Service principal
    05/02/2021 19:06:05  06/02/2021 05:06:05  krbtgt/AD.TRANQUIL.IT@AD.TRANQUIL.IT
            renew until 06/02/2021 19:06:05

Attempting an authentication with curl

  • on the linux machine:

      [root@srvwapt.ad.tranq ~]# kdestroy
      [root@srvwapt.ad.tranq ~]# kinit sfonteneau
      Password for sfonteneau@AD.TRANQUIL.IT:
      [root@srvwapt.ad.tranq ~]# klist
      Ticket cache: FILE:/tmp/krb5cc_0
      Default principal: sfonteneau@AD.TRANQUIL.IT
      Valid starting       Expires              Service principal
      05/02/2021 19:10:42  06/02/2021 05:10:42  krbtgt/AD.TRANQUIL.IT@AD.TRANQUIL.IT
              renew until 06/02/2021 19:10:39
      root@srvwapt.ad.tranq ~]# curl -v --negotiate -u : https://srvwapt.ad.tranquil.it/add_host_kerberos -k
      * Expire in 0 ms for 6 (transfer 0x563dece09f90)
      * Uses proxy env variable no_proxy == 'localhost,127.0.01/8,,,,ad.tranquil.it'
      * Expire in 1 ms for 1 (transfer 0x563dece09f90)
      * Expire in 0 ms for 1 (transfer 0x563dece09f90)
      * Expire in 0 ms for 1 (transfer 0x563dece09f90)
      *   Trying
      * TCP_NODELAY set
      * Expire in 200 ms for 4 (transfer 0x563dece09f90)
      * Connected to srvwapt.ad.tranquil.it ( port 443 (#0)
      * ALPN, offering h2
      * ALPN, offering http/1.1
      * successfully set certificate verify locations:
      *   CAfile: none
        CApath: /etc/ssl/certs
      * TLSv1.3 (OUT), TLS handshake, Client hello (1):
      * TLSv1.3 (IN), TLS handshake, Server hello (2):
      * TLSv1.2 (IN), TLS handshake, Certificate (11):
      * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
      * TLSv1.2 (IN), TLS handshake, Request CERT (13):
      * TLSv1.2 (IN), TLS handshake, Server finished (14):
      * TLSv1.2 (OUT), TLS handshake, Certificate (11):
      * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
      * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
      * TLSv1.2 (OUT), TLS handshake, Finished (20):
      * TLSv1.2 (IN), TLS handshake, Finished (20):
      * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
      * ALPN, server accepted to use http/1.1
      * Server certificate:
      *  subject: C=FR; ST=PDLL; L=Saint Sebastien sur Loire; O=Tranquil IT Systems; OU=TIS; CN=srvwapt.ad.tranquil.it; name=PKI TIS; emailAddress=technique@tranquil.it
      *  start date: Aug  3 12:48:03 2017 GMT
      *  expire date: Aug  1 12:48:03 2027 GMT
      *  issuer: C=FR; ST=PDLL; L=Saint Sebastien sur Loire; O=Tranquil IT Systems; OU=TIS; CN=Tranquil IT Systems CA; name=PKI TIS; emailAddress=technique@tranquil.it
      *  SSL certificate verify ok.
      > GET /add_host_kerberos HTTP/1.1
      > Host: srvwapt.ad.tranquil.it
      > User-Agent: curl/7.64.0
      > Accept: */*
      < HTTP/1.1 401 Unauthorized
      < Server: nginx
      < Date: Fri, 05 Feb 2021 18:08:38 GMT
      < Content-Type: text/html
      < Content-Length: 188
      < Connection: keep-alive
      < WWW-Authenticate: Negotiate
      < WWW-Authenticate: Basic realm=""
      * Ignoring the response-body
      * Connection #0 to host srvwapt.ad.tranquil.it left intact
      * Issue another request to this URL: 'https://srvwapt.ad.tranquil.it/add_host_kerberos'
      * Uses proxy env variable no_proxy == 'localhost,127.0.01/8,,,,ad.tranquil.it'
      * Found bundle for host srvwapt.ad.tranquil.it: 0x563dece07590 [can pipeline]
      * Could pipeline, but not asked to!
      * Re-using existing connection! (#0) with host srvwapt.ad.tranquil.it
      * Connected to srvwapt.ad.tranquil.it ( port 443 (#0)
      * Expire in 0 ms for 6 (transfer 0x563dece09f90)
      * Server auth using Negotiate with user ''
      > GET /add_host_kerberos HTTP/1.1
      > Host: srvwapt.ad.tranquil.it
      > Authorization: Negotiate YIIGagYGKwYBBQUCoIIGXjCCBlqgDTALBgkqhkiG9xIBAgKiggZHBIIGQ2CCBj8GCSqGSIb3EgECAgEAboIGLjCCBiqgAwIBBaEDAgEOogcDBQAgAAAAo4IFOmGCBTYwggUyoAMCAQWhEBsOQUQuVFJBTlFVSUwuSVSiKTAnoAMCAQOhIDAeGwRIVFRQGxZzcnZ3YXB0LmFkLnRyYW5xdWlsLml0o4IE7DCCBOigAwIBEqEDAgEDooIE2gSCBNac76E6ITct2DXZXMxVNKO5cvgXwU6F9LpnN7Zf6M2AEhvnDAaeD5VOqq/+lGapoxK1hCC62Mnye9zF4SzOEKBDLPD77KJp2xbW227lc5ZF/22wGXn8n6Sw1xndf1brq1mSEUo0TzpFUfY1wNoRDaw7WUNhQK2nbTTeMrsiiPACuQtG82W0VrZJZ+4z1Gq3ZFTLYUrlC010S1T8pNRzCLFRb47Q15B1f7rPAqaZLO/OBq9EQd+i/2Mfp8XWy46gGRtezTk8Dya+SH3henhB+L7G4ew0c3MKxFRkv0nXQ65qPAXWyogbivI/ReekU1anHLnGfDyfeBw2QUM8t2kEEcSBmNKfrQ1U/u1jnlRZJ1o067PiziZsH7w/zGpe7uhOa8a4RKYu1LeJEuU+CKrufulQWKuqdiwIBdq9ApoQqduCbNsE9ihH1srL3RYh9XdQ4Unx51eo49nZQA+c2Aj4JvCafbY/jeRBw6SNYCrfGETN1mXytjLRyVBtJlch7djBGUAYaH1HGNfEVt+VnCW4O9OoqgC0M++u6d7Ci5w494ZseNXnF7RBKr01aVEt0231geGglNvTyXzWJ3IGUOrhBnaTTSLAzai/arutH6c3CzLb+xPMAOUtCIup0M43SR0DC7gJ/xZ3BZyKHF6b3p3tAWiByat2XNMxfMbgjaiv7oLCNEIAga0IgTg5f0nlahTI9323vfIH8aLNNVYVJeFKNGX1ord0YpJ3RLDshNBnoDTPyCKnXcf5nM+tqabshzatuTP6PfFkal6evwZ/QXiFQAezmRut+hfXtoVch8LHC0OIaloDUk1eHlFbAqQ98OaE3SZ8Fx4m8Nw3JgQ0E+zXPt8DJCnNY4YV4j3+9b1093XhsJRyP97qEFazUGFhfg7/PzqFnxSHtikXjCnjtzfuHLePMWn0HKFbL/hEMmAnfZ15JiBgfBi82OXv3rCui+GKT/ZsjUFsgR8tCUJ58/gXBu9J/gY1R46CvWTnl03+2JHQyomm6k0XnAU+s2hX+n/QcKbIjT7ew/f/UuT0J1YV+bQ8MMTpQqbau4f5sVaembIB7hTVyttpfbBEqCOVk39xZ/r8b9CMpmukShPgeJI0x353i7bO9/mBkchFaeyOc45jA7Z4iJ3IHNiWLaWyYLktH/1N9/dXas8/CoZK0UsKjm9+xlkFFSP18CFHijILlIc1sTdMnAil/jwqQl1W2WRnBlt8r/yE56EDR/i8VkCMHT5XsiiMCHm4LldkmDnIo/+GgHTG+3Z78Pkq939rMati/gzd9geYM8aUuYwJpcb53YsjWvJD1gDEHEwS3K1MYxbyy9eiODCOCgvIeKmVPouNrugXs4TX6PJsCQDtzusSWxmZY4820HxmJkNT1lG5ZkktyHGsMjHnBLlSz5Ex01CnxwjVOHmSOrYfJnTzqYP5AF648wHbQ9ArikXg0pBQVQ832ChwR18N3jH5xeUljq3fjGzxA27YD6nTg6SV7hdcDkXmJvjUbIwGjrtfZU/b93cbD4oaOWlbPViBpwLZ+TTCkeGAxo3eBicENHSK81EIJYMBfEWTTsjYPEPsl5BK7IFcqArfEWG6HQDw3bOfYAB1ZJb0zSbhyD/rKnRmtSke/eWIAjYaeHDX0qYMruJCuI2lYofHtFwMEKSB1jCB06ADAgESooHLBIHIDVUTdDas6nA0obxBuM2bQiZ0ZUPhAVGMoTniuCmBXU/mFRAsD029zDjfl0nzeFsPdC4UBERcc8Vh4r3YeZIxUxzn5tXCW4oFypYi5kHAdx6Zd4GkZcEpzAhRF7JwSylerZiCF+fnSIiI5wdDG56PMFf46ZnT0gSnYiqYGWCv7y1pdc3P9VViECBNjpGSc9sn9fZ2HFTGaiuGLl1G8Jyjkymn2cilE0MOBpYuFUXnvyYErT5jajyKOUMexTCS1FxneLNUK6jBlWE=
      > User-Agent: curl/7.64.0
      > Accept: */*
      < HTTP/1.1 200 OK
      < Server: nginx
      < Date: Fri, 05 Feb 2021 18:08:38 GMT
      < Content-Type: text/html; charset=utf-8
      < Content-Length: 38
      < Connection: keep-alive
      < WWW-Authenticate: Negotiate oYG3MIG0oAMKAQChCwYJKoZIhvcSAQICooGfBIGcYIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvQoZWpMIm8fS3ZrHmI96KuJ4AnP1ztIwCCXGJy3HuI2++IQ4cccbhf2WLdbxjaf82eOb4MQDZDq8F/x0oFJX6n4DnhPZxrq/RnjwkoTnik7R8MJkKRuvYncBfTGBIHvTJktq6+j9pHqmBDH5D5L8A
      < WWW-Authenticate: Basic realm=""
      < Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
      < Pragma: no-cache
      * Closing connection 0
      keberos connection seems to be working

Verifying that you are successful obtaining a Kerberos ticket


Always execute commands in system account (see previous point)!

klist purge
klist get http/srvwapt.ad.mydomain.lan

You must get:

C:\Windows\System32>klist get http/srvwapt.ad.mydomain.lan

LogonId est 0:0x13794d
Un ticket pour http/srvwapt.ad.mydomain.lan a été récupéré.

Tickets mis en cache : (2)

#0>     Client : sfonteneau @ AD.MYDOMAIN.LAN
                Serveur : krbtgt/AD.MYDOMAIN.LAN @ AD.MYDOMAIN.LAN
                Type de chiffrement KerbTicket : AES-256-CTS-HMAC-SHA1-96
                Indicateurs de tickets 0x40e00000 -> forwardable renewable initial pre_authent
                Heure de démarrage : 2/4/2021 15:51:07 (Local)
                Heure de fin :   2/5/2021 1:51:07 (Local)
                Heure de renouvellement : 2/11/2021 15:51:07 (Local)
                Type de clé de session : AES-256-CTS-HMAC-SHA1-96
                Indicateurs de cache : 0x1 -> PRIMARY
                KDC appelé : srvads.AD.MYDOMAIN.LAN

#1>     Client : sfonteneau @ AD.MYDOMAIN.LAN
                Serveur : http/srvwapt.AD.MYDOMAIN.LAN @ AD.MYDOMAIN.LAN
                Type de chiffrement KerbTicket : AES-256-CTS-HMAC-SHA1-96
                Indicateurs de tickets 0x40a80000 -> forwardable renewable pre_authent 0x80000
                Heure de démarrage : 2/4/2021 15:51:07 (Local)
                Heure de fin :   2/5/2021 1:51:07 (Local)
                Heure de renouvellement : 2/11/2021 15:51:07 (Local)
                Type de clé de session : AES-256-CTS-HMAC-SHA1-96
                Indicateurs de cache : 0
                KDC appelé : srvads.AD.MYDOMAIN.LAN

If that does not work, check in your Active Directory that the serviceprincipalname attribute on the computer account of the WAPT server has this value: HTTP/srvwapt.mydomain.lan.

Check that it works with a browser


You must first configure firefox for kerberos authentication.

  • type about:config in the URL bar in your firefox;

  • edit network.negotiate-auth.trusted-uris, and add the url of the wapt server: srvwapt.mydomain.lan;

  • you can now visit the url: https://srvwapt.mydomain.lan/add_host_kerberos;

  • if the authentication does not work, then the server will return a 403 error message;

In case of an error on one of the previous checks

  • delete the machine’s account from the active directory;

  • delete the /etc/nginx/http-krb5.keytab file;

  • reboot the host you are testing with and run the keytab creation process again;


  • it is important to restart the machine to purge the kerberos tickets previously obtained by the machine;

  • to avoid restarting you can also execute the command “klist purge” as SYSTEM;

Activating the verification of the SSL / TLS certificate

When running the WAPT Server post-configuration script, the script will generate a self-signed certificate in order to enable HTTPS communications.

The WAPT agent checks the HTTPS server certificate according to the verify_cert value in section [global] in C:\Program Files (x86)\wapt\wapt-get.ini.

Options for verify_cert

Options for verify_cert

Working principle of the WAPT agent

verify_cert = 0

the WAPT agent will not check the WAPT Server HTTPS certificate

verify_cert = 1

the WAPT agent will check the WAPT Server HTTPS certificate using the certificate bundle C:\Program Files (x86)\wapt\lib\site-packages\certifi\cacert.pem

verify_cert = C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt

the WAPT agent will check the WAPT Server HTTPS certificate with the certificate bundle C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt


To quickly and easily enable verification of the https certificate, you can use the Pinning method.

Pinning the certificate

The pinning of certificate consists of verifying the SSL/ TLS certificate with a well defined and restricted bundle.


This method is the easiest when using a self-signed certificate.

For this, you need to launch the following commands in the Windows cmd.exe shell (with elevated privileges if UAC is active).

If you already have a Windows cmd.exe shell open, close it and open a new shell so to take into account the updated environment variables:

wapt-get enable-check-certificate
net stop waptservice
net start waptservice

Validate the certificate with wapt-get update

When you have executed the update command, make sure that everything has gone well, and if in doubt check Problems when enabling enable-check-certificate.


  • the command enable-check-certificate downloads the certificate srvwapt.mydomain.lan.crt in the folder C:\Program Files (x86)\WAPT\ssl\server;

  • it then modifies the file wapt-get.ini to specify the value verify_cert = C:\Program Files (x86)\wapt\ssl\server\srvwapt.mydomain.lan.crt;

  • the WAPT agent will now verify certificates using the pinned certificate;


If you use the certificate pinning method, be reminded to archive the /opt/wapt/waptserver/ssl folder on your WAPT Server.

The file will have to be restored on your server if you migrate or upgrade your WAPT Server, if you want the WAPT agents to continue to be able to establish trusted HTTPS connections.

How to use a commercial certificate or certificates provided by your organization?

If the pinning method does not suit you, you can replace the self-signed certificate generated during the installation of WAPT.

Replace the old certificate with the new one in the folder /opt/wapt/waptserver/ssl/ (linux) or c:\wapt\waptserver\ssl\ (windows).

The new key pair must be in PEM encoded Base64 format


Special case where your certificate has been signed by an internal Certificate Authority

Certificates issued by an internal Certificate Authority must have the complete certificate chain up to the Certificate Authority’s certificate.

You can manually add the certificate chain up to the Certificate Authority to the certificate that will be used by Nginx.

Example: echo srvwapt.mydomain.lan.crt ca.crt > cert.pem

For linux servers it is also necessary to reset the ACLs:

chown root:www-data /opt/wapt/waptserver/ssl/*.pem

chown root:nginx /opt/wapt/waptserver/ssl/*.pem
  • restart Nginx to take into account the new certificates;

    • Linux:

      systemctl restart nginx
    • Windows:

      net stop waptnginx
      net start waptnginx

Configuring the WAPT agent

For a commercial certificate you can set verify_cert = 1 in wapt-get.ini.

For a certificate issued by an internal Certificate Authority, you must place the certificate in the C:\Program Files (x86)\wapt\ssl\server\ca.crt folder and specify the certificate path in verify_cert in the agent’s wapt-get.ini.

To apply the new configuration to your entire fleet, you can regenerate a WAPT agent with the appropriate settings.

Verifying the certificate in the WAPT console

When the WAPT console first starts, it reads the content of C:\Program Files (x86)\WAPT\wapt-get.ini and it builds its configuration file C:\Users\admin\AppData\Local\waptconsole\waptconsole.ini.

This properly sets the verify_cert attribute for the HTTPS communication between the WAPT console and the WAPT Server.

Configuring user authentication against Active Directory

New in version 1.5: Enterprise


Feature only available with WAPT Enterprise.

By default, the WAPT Server is configured with a single SuperAdmin account whose password is setup during initial post-configuration.

On large and security-minded network, this SuperAdmin account should not be used since it cannot provide the necessary traceability for administrative actions that are done on the network.

It is thus necessary to configure authentication against the Organization’s Active Directory for the Administrators and the Package Deployers; this will allow to use named accounts for administrative tasks.


  • Active Directory authentication is used to authenticate access to the inventory via the WAPT Console;

  • however, all actions on the WAPT equipped remote devices are based on X.509 signatures, so an Administrator will need both an Active Directory login AND a private key whose certificate is recognized by the remote devices to manage his installed base of devices using WAPT;

  • only the SuperAdmin account and the members of the Active Directory security group waptadmins will be allowed to upload packages on the main repository (authentication mode by login and password);

Enabling Active Directory authentication

  • to enable authentication of the WAPT server on Active Directory, configure the file /opt/wapt/conf/waptserver.ini as follows:

Available authentication options






DN to the group name. All members of this group will be able to connect to WAPT



LDAP server that will be used by WAPT



DN for the search


True / False

Default value: True

  • restart waptserver with systemctl restart waptserver;


For Microsoft Active Directory, Microsoft has announced that SimpleBind authentication on MS-AD without SSL/TLS will be blocked by default from April 2020. If you don’t have a certificate installed, you’ll have to modify a registry key to have authentication working.


By default Samba-AD does not allow SimpleBind authentication without SSL/TLS. If you do not have a valid certificate you’ll need to modify the ldap server require strong auth parameter in /etc/samba/smb.conf. For more information you may refer to Tranquil IT documentation on https://dev.tranquil.it/samba/en/index.html.

Enabling SSL/ TLS support for the LDAP connection to the Active Directory Domain Controller

By default, authentication on Active Directory relies on LDAP SSL (default port 636).

SSL/ TLS is not enabled by default on Microsoft Active Directory until a SSL certificate has been configured for the Domain Controller.


The WAPT Server uses the Certificate Authority bundles from the operating system (CentOS) for validating the SSL/ TLS connection to Active Directory.

If the Active Directory certificate is self-signed or has been signed by an internal CA, you’ll need to add these certificates to the certificate store of CentOS.

Add a Certificate Authority in the /etc/pki/ca-trust/source/anchors/ and update the CA store.

cp cainterne.pem /etc/pki/ca-trust/source/anchors/cainterne.pem
  • once you have setup LDAP SSL/ TLS on your Active Directory (please refer to Microsoft documentation for that), then you can enable support for SSL/ TLS security for AD in /opt/wapt/conf/waptserver.ini:

    ldap_auth_ssl_enabled = True
  • restart waptserver with systemctl restart waptserver;

Configuring Client-Side Certificate Authentication

New in version 1.7: Enterprise


This feature is only available with WAPT Enterprise.

If your business needs a public WAPT server on Internet, it can be secured with Client-Side Certificate Authentication.

That configuration restricts the visibility of the WAPT Server to registered clients only. It is done by relying on the WAPT agent private key generated during registration. It works as follows:

  • the WAPT agent sends a CSR to the WAPT server which the WAPT server signs and sends back to WAPT agent;

  • using the signed certificate, the agent can access protected parts of the Nginx web server;


We advise you to enable kerberos or login / password registration in WAPT Server post-configuration.

Enabling Client-Side Certificate Authentication

  • be sure to unset the custom headers relative to client side authentication results when requests are proxied without being checked by nginx ssl module. These headers are trusted by the waptserver if X-Ssl-Authenticated is SUCCESS and waptserver.ini parameter use_ssl_client_auth is set to True:

    location / {
        proxy_set_header X-Ssl-Authenticated "";
        proxy_set_header X-Ssl-Client-DN "";
  • add a Nginx configuration file /etc/nginx/certificate-auth.conf. This file is used to restrict access to specific actions with Certificate Authentication:

    proxy_set_header X-Ssl-Authenticated $ssl_client_verify;
    proxy_set_header X-Ssl-Client-DN $ssl_client_s_dn;
    if ($ssl_client_verify != SUCCESS) {
        return 401;

Example config file:

server {
    listen                      80;
    listen                      443 ssl;
    server_name                 _;

    ssl_certificate             "/opt/wapt/waptserver/ssl/cert.pem";
    ssl_certificate_key         "/opt/wapt/waptserver/ssl/key.pem";
    ssl_protocols               TLSv1.2;
    ssl_dhparam                 /etc/ssl/certs/dhparam.pem;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_stapling                on;
    ssl_stapling_verify         on;
    ssl_session_cache           none;
    ssl_session_tickets         off;

    gzip_min_length     1000;
    gzip_buffers        4 8k;
    gzip_http_version   1.0;
    gzip_disable        "msie6";
    gzip_types          text/plain text/css application/json;
    gzip_vary           on;

    ssl_client_certificate "/opt/wapt/conf/wapt-serverauth-ca.crt";
    ssl_verify_client optional;

    index index.html;

    location /static {
        alias "/opt/wapt/waptserver/static";

    location / {
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        # be sure we ignore these headers if they are coming from clients
        proxy_set_header X-Ssl-Client-Dn  "";
        proxy_set_header X-Ssl-Authenticated  "";

        client_max_body_size 4096m;
        client_body_timeout 1800;

        location ~ ^/(wapt|wapt-host|waptwua)/(.*)$ {
            proxy_set_header Cache-Control "store, no-cache, must-revalidate, post-check=0, pre-check=0";
            proxy_set_header Pragma "no-cache";
            proxy_set_header Expires "Sun, 19 Nov 1978 05:00:00 GMT";

            include /etc/nginx/certificate-auth.conf;

            rewrite ^/(wapt|wapt-host|waptwua)/(.*)$ /$1/$2 break;
            root "/var/www";

        # kerberos auth
        location /add_host_kerberos {
            auth_gss on;
            auth_gss_keytab  /etc/nginx/http-krb5.keytab;

        # basic auth
        location ~ ^/(add_host|ping)$ {

        location /wapt-host/Packages {
                return 403;

        location / {
            include /etc/nginx/certificate-auth.conf;


        location /socket.io {
            include /etc/nginx/certificate-auth.conf;
            proxy_http_version 1.1;
            proxy_buffering off;

            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";




Be careful, as of 2021-04-07, WAPT does not support CRL, which means that when you delete a machine in the WAPT console, the machine will still have access to the WAPT repository.

Configuring Access Control Lists