The new certificate will not be a self-signed certificate;
This new certificate will be signed by the CA (the key generated at the time of the first installation of WAPT);
You MUST then fill in the Authority Signing Key and the Authority Signing Certificate.
When generating the new pem/ crt pair, you have the option to choose whether or not the new certificate will be a Code Signing type.
Hint
For recall, a Code Signing certificate is reserved to individuals with the Administrator role in the context of WAPT and a simple SSL certificate without the CodeSigning attribute is reserved to individuals with the role of Package Deployer.
Administrators will be authorized to sign packages that CONTAIN a setup.py executable file (i.e. base packages).
Individuals with the Package Deployer role will be authorized to sign packages that DO NOT CONTAINsetup.py executable file (i.e. host, unit and group packages).
Generating a certificate without the Code Signing attribute¶
Keys and certificates that are Not Code Signing may be distributed to individuals in charge of deploying packages on the installed base of WAPT equipped devices.
Another team with certificates having the Code Signing attribute will prepare the WAPT packages that contain applications that will need to be configured according to the security guidelines of the Organization and the user customizations desired by her.
Generating a certificate with the Code Signing attribute¶
Generating a new .pem / .crt pair will also allow to formally identify the individual who has signed a package by looking up the CN attribute of the WAPT package certificate.
Hint
The new certificates will not be CA Certificates, which means that they will not be authorized to sign other certificates.
As a general rule, there is only one CA Certificate pem / crt pair per Organization.
Attention
It is not necessary to deploy child certificates with the WAPT Agent.
Child certificates are used with the WAPT Console to allow or restrict actions.
11.1.2. Deploying certificates of local IT admins on clients¶
Hint
Some Organizations will choose to let local IT administrators perform actions on WAPT equipped devices by issuing them personal certificates that will work on the set of devices for which the local IT admins are responsible.
The headquarter IT admins will deploy the certificates of local IT admins on the computers that local admins manage on their respective sites.
This way, local IT admins will not be able to manage computers located in headquarters, but on their own sites only.
It is possible to manage simply and in a finer way using Access Control Lists with the Enterprise version of WAPT.
You will need to copy the certificates of allowed local IT admins on WAPT clients in C:\programfiles(x86)\wapt\ssl.
Hint
Do not forget to restart the WAPT service on clients for them to use their new certificate.
Open a command line cmd.exe.
The SuperAdmin user of WAPT is authenticated by a password stored in waptserver.ini as a value of the wapt_password attribute.
Others WAPT users may be local users htpasswd_path) or AD account users (ldap_auth_server / ldap_auth_base_dn).
ACLs define actions enabled for all types of users in the WAPT context.
Note
Default ACLs user level are defined by default_ldap_users_acls in waptserver.ini.
The default ACL for a new user is view.
Attention
Security is define by the certificate deployed on clients, not by ACLs.
ACLs simply limit what actions the WAPT Server is allowed to relay from the WAPT Console to the WAPT Agents.
As of 2026-06-15 , the WAPT Agents do not check ACL rights.
To configure ACLs in WAPT, go to Server → Manage WAPT users and rights.
Note
On first launch after the WAPT Server installation, only the SuperAdmin account is present in the list of users.
If the SuperAdmin account does not exist or does not have the admin right, then the account is recreated by restarting the WAPT Server service.
The SuperAdmin account is authenticated using the value of wapt_password in the waptserver.ini configuration file.
If the local user has a password in waptusers.htpasswd, then the username appears in bold and Local User is checked, else change the password for this user.
Denies any edit right to any package (not checked).
Allow any packages
Allows edit right to all WAPT packages.
Allow specific packages name
Allows edit right for the WAPT packages selected in the list.
11.4. Re-signing packages on the WAPT Server using the WAPT console¶
It is possible that a package was created by a WAPT user whose certificate is not recognized on certain machines.
However, the package might still be suitable for those machines.
In such cases, you can re-sign the package using the certificate of another WAPT user who has higher privileges within the network.
Go to Packages inventory, identify your package and do right-click Resign packages.
A browser window will open, prompting you to grant access to the application. Check the consent box for your organization.
Expected Output:
Code: 1.AR8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.AgABBAIAAABVrSpeuWamRam2jAF1XRQEAwDs_wUA9P9CWi14DUUxhFdifAJG6aygRZwO_bcwGzCXOSlkGUD_YmYsWHGIiBHLiUX5lWnYU0qk847CCOmJxnKZyDepL6-d40yYYhHq
...
ClientSecret is known, using it to exchange code for a token...
Token: {"aud":"00000003-0000-0000-c000-000000000000","iss":"https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/","iat":1758812637,"nbf":1758812637,"exp":1758817061,"acct":0,"acr":"1","acrs":
[...0","b79fbf4d-3ef9-4689-8143-76b194e85509"],"xms_ftd":"4Bv2ZusNHcpIBqPAClu5jRjnL-ldhsTz0S54w-3nbrABZXVyb3Bld2VzdC1kc21z","xms_idrel":"1 10","xms_st":{"sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8"},"xms_tcdt":1517
233874,"xms_tdbr":"EU"}
ID Token: {"aud":"7198c7eb-bff0-423b-b15e-e740dbe3ff28","iss":"https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0","iat":1758812637,"nbf":1758812637,"exp":1758816537,"rh":"1.A
R8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.","sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8","tid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","uti":"cABi3a7vQECEsCD_EAVUAA","ver":"2.0"}
User authenticated: XXXX XXXXXXX
End session: 1
6. Assign Application Roles:
In Microsoft Entra ID, navigate to Enterprise Applications.
Select your newly registered application.
Go to Users and groups > Add user/group.
Select the users who will have the waptadmins role.
7. Verify Role Assignment in Token:
Test the authentication again with the following command:
Ensure the token contains the role assignment: "roles":["waptadmins"].
8. Configure Roles in the WAPT Console:
Log in to the WAPT console with an admin account.
Navigate to User and Rights Management.
Check Roles > New Role.
Rename the default role (e.g., role1) to waptadmins.
Assign the desired permissions, then close the window and log out.
Reopen the console and log in using the OAuth2/OpenID Connect option.
Bearer Token
A Bearer Token can be generated using various authentication methods to verify the user’s identity, such as Kerberos or username/password credentials.
To enable this feature, add token to the login_auth_methods parameter in the waptserver.ini file. After making this change, restart the WAPT services to apply the modifications:
systemctlrestartwaptserverwapttasks
How to create a token examples:
Open a command prompt on the machine
Run wapt-getserver-login and enter your credentials (local account or user@mydomain.lan)
A token will be generated, which you can use to access the console
Run wapt-getserver-login--login_method=sessionkerberos
A token will be generated, which you can use to access the console
Note
For this moment token have a lifetime to 12h, to change it you can modify the value of the token_lifetime in the file /opt/wapt/waptserver/config.py .
x509 certificate
It is possible to connect to the WAPT Console using an X.509 certificate. This method provides a secure and passwordless authentication option.
How to configure it
In the WAPT Console:
Create a User Certificate: Generate a certificate with the same name as the user (example: certificate john for user john@domain.lan ).
Associate the Certificate with the User: In the WAPT Console, go to User Rights Management and link the certificate to the user.
In the WAPT Console, navigate to Server > Manage WAPT Users and Rights (ACLs).
Select the desired user.
Click Register User Certificate and upload the user’s X.509 certificate.
In the WAPT Server:
Update waptserver.ini: Add ssl to the authentication methods parameter login_auth_methods.
Create a Client Certificates File: Create a file (e.g., /opt/wapt/conf/ca-clients.crt) and append the public parts of user certificates to it.
Configure Nginx: Edit /etc/nginx/sites-enabled/wapt.conf and modify the line : ssl_client_certificate “/opt/wapt/conf/ca-clients.crt”.
¶
