Certificates Management

Overview

This guide provides information on how to issue and revoke different types of certificates (user, server, client, and mobile).

Certificates issued by the Rsignd component are stored in two different locations based on their type:

User/admin certificates: These are stored in the user account in the user certificate LDAP attribute according to your LDAP infrastructure. WebADM supports storing user certificates in both binary and base64 encoding. The encoding is specified in the objects specification file located at /opt/webadm/conf/objects.xml. Note that private keys are never stored in this attribute. Certificate attributes are defined by the certificate_attrs setting in the WebADM main configuration file at /opt/webadm/conf/webadm.conf.
- admin certificates can be issued only from the WebADM Administrator portal and the Manager APIs.
- user certificates can be issued by an administrator from the WebADM Administrator portal and the Manager API. A user certificate can also be issued by the end-user directly from the Self-services applications provided by RCDevs.
Other types of certificates: These are stored in the certificate table of the SQL database configured with the WebADM framework. They can be issued through the WebADM Administrator portal and through the Manager API.

User/Administrator certificates

Purposes

An Admin certificate can be used for various purposes such as logging in to the WebADM Administrator portal and Web Applications like SelfDesk and Helpdesk and for EAP-TLS authentications. They can also be used for S-MIME purposes, Smart-Card logins on Windows with the OpenOTP Credential Provider, and the OpenOTP SOAP API with the PKI login method. User/Admin certificates can also be used for authentication on Wifi networks.

Admin certificates can only be issued to super_admins defined in /opt/webadm/conf/webadm.conf.

A User certificate can be used for the same purposes except for logging in to the WebADM Admin Portal.

The main notable differences between these two types of certificates are the values contained in the subject and description fields.

An admin certificate will contain the DistinguishedName value of the user for whom the certificate has been issued in the subject field, and the description field will contain the Admin value. A user certificate will contain the DOMAIN\Username value of the user for whom the certificate has been issued, and the description will contain the USER value. The DOMAIN value refers to the WebADM domain the user is part of.

See below, details contained in each type.

Admin certificate type:

User certificate type:

Issue User/Administrator certificate

From the WebADM Administrator portal, navigate to the account for which you want to issue a certificate. Once on the user's profile, in the LDAP actions box, click Create certificate.

Certificate validity period: Defines how long the certificate will remain valid. This period is limited to the default_cert_validity setting in the Rsignd signing server configuration file (conf/rsignd.conf).
Certificate Export Format: PKCS12 or PEM format. Note that the PEM format is not password protected compared to PKCS12 and PEM format may not be accepted by all client during the import (e.g Windows).
Email address: If the user has an email address defined, you can select one email address to be part of the certificate information.
Send email Notification: If the user has an email address defined, WebADM can automatically send the new certificate package to the user's email address. The PKCS12 package is encrypted by WebADM with a random password that is not sent in the email.
Certificate usage: Admin or User.
Extended Key Usage (EKU): Secure Email (S/MIME), Microsoft Smartcard login EKU can be optionnaly added if you want to use it for that purpose.

Provide the necessary information and click the Create Cert button. A PKCS12 package will be generated, protected by a password which will be prompted at the end of the issuing process. Download the package and save the password. You will need the password later to import the certificate and its key into your Certificate Trust Store. Click Ok to leave the current page. The certificate has been successfully issued and is now usable with RCDevs solutions/integrations.

Upon returning to the user account LDAP view, you will now see the user certificate attribute containing the issued certificate. From the same view, on the certificate, there are 4 possible actions:

-Renew: Allows you to renew a certificate. A new PKCS12 bundle will be created.

-Details: Allows you to view and read all information contained in the certificate. It provides the equivalent of reading an SSL certificate with OpenSSL.

-Download: Allows you to download the public part of the certificate in CRT/PEM format.

-Remove/Revoke: Finally, there is a checkbox next to each certificate. Select the certificate you want to remove by clicking the checkbox, then scroll down and click the Apply Changes | Re-Encrypt | Delete Selected button at the bottom of the page. This will remove the certificate entry from the account. If there is only one certificate enrolled on the user account, click the Delete Attribute button to remove it.

For more information on how user/admin certificate revocation works, refer to the next section.

Revoke a User/Administrator certificate

A User/Administrator certificate is considered revoked as soon as it has been removed from the user account.

To revoke a certificate, click on the checkbox next to the certificate, scroll down on the page, and click Apply Changes | Re-Encrypt | Delete Selected button. The certificate is now revoked and unusable.

Starting with WebADM 2.3.19, revoked administrator/user certificates are now added to the CRL and OCSP service provided by RCDevs. This was not the case for the CRL service before WebADM 2.3.19.

Client certificate

Purposes

Client certificates can serve multiple key usages, including:

Device Authentication on EAP-TLS for Ethernet Networks: Client certificates are essential for authenticating devices in EAP-TLS environments, ensuring secure access to Ethernet networks.
Client Integration Consuming Web Services: For services like OpenOTP and Spankey, a valid client certificate can be required for integration. This is particularly relevant for client integration tools such as the OpenOTP Credential Provider for Windows and the OpenOTP Plugin for Mac OS, which use certificates to authenticate and authorize access.
Network Access Control (NAC): In NAC scenarios, a client certificate can be linked to a device's MAC address. This binding ensures that the certificate is usable only from the specific device it is associated with, enhancing security by preventing certificate misuse on unauthorized devices.
SSL/TLS Communications: Client certificates can also be used for any purposes regarding SSL/TLS communications between a client and a server, ensuring secure and encrypted connections.

Issue Client certificate

A client certificate can be issued or approved (in an automated process) by WebADM administrators only. This can be done through the WebADM Administrator portal or via the Manager API.

To issue a client certificate from WebADM Administrator Portal, log in to the WebADM Administrator portal, click on the Admin tab, and then select Create Server or Client SSL certificate.

Set the Certificate Type to Client, and provide the Client Name or Description for the client you want to issue the certificate to. You can restrict the usage of the client certificate to a specific application, such as OpenOTP, Spankey, or SMSHub, by configuring the Restricted Application. In that case, the usage will be limited to the configured application. This setting will have no effect outside of the WebADM framework.

Adjust the Certificate validity if you want a validity period different from the default configuration. Optionally, you can set a password to protect the private key.
Note that protecting the private key with a password will require you to provide the password whenever a service using that certificate and key pair starts. For example, when you start an Apache server, you will be prompted to provide the password before the service starts. This can be risky because if your server restarts for any reason, you will need to provide the password to get the service back up and running.

You can also provide optional information such as Alternative Names, Country Name, Locality Name, State or Province, and Email Address, which will be part of the certificate.

Starting with WebADM 2.3.17, a new feature allows you to return RADIUS Attribute-Value Pairs (AVPs) if they are defined during the client certificate issuing process. This enables you to control third-party systems, such as switches, when EAP-TLS is implemented. For example, you can return a VLAN ID to a specific machine using that certificate for Network Access Control (NAC) purposes.

Revoke Client certificate

As mentioned previously, client certificates are stored in the Certificate table of the SQL database. To revoke a client certificate, it must be retained in the SQL database and flagged as disabled by switching the enabled radio button. It is important to keep it in the database until its expiration; otherwise, the OCSP and CRL services will not provide information about the revocation. The revocation status can be removed by switching the radio button, making the certificate reusable.

Server certificate

Purposes

Server certificates can serve multiple key usages, including:

Authentication: Verifies the identity of the server to clients, assuring users that they are communicating with the intended website or server.
Encryption: Uses cryptographic algorithms to encrypt data exchanged between the server and clients, ensuring confidentiality and preventing eavesdropping.
Trust: Issued by trusted CAs, which are entities that validate the identity of the certificate holder, ensuring trustworthiness and reliability.

Issue Server certificate

Set the Certificate Type to Server, provide the Server hostname (FQDN) for the server you want to issue the certificate for, and adjust the validity if required. Optionally, you can set a password to protect the private key. Note that protecting the private key with a password will require you to provide the password whenever a service using that certificate and key pair starts. For example, when you start an Apache server, you will be prompted to provide the password before the service starts. This can be risky because if your server restarts for any reason, you will need to provide the password to get the service back up and running.

You can also provide optional information such as Alternative Names, Country Name, Locality Name, State or Province, and Email Address which will be part of the certificate.

Revoke Server certificate

As mentioned previously, server certificates are stored in the Certificate table of the SQL database. To revoke a server certificate, it must be retained in the SQL database and flagged as disabled by switching the enabled radio button. It is important to keep it in the database until its expiration; otherwise, the OCSP and CRL services will not provide information about the revocation. The revocation status can be removed by switching the radio button, making the certificate reusable.

Mobile certificate

Purposes

Mobile certificate has only one usage which is the document signing purposes from OpenOTP Token application.
OpenOTP provides electronic signature APIs and signature request involving a user certificate (Advanced signature with local scope) for signing operation.

Issue Mobile certificate

Such certificates can only be issued during the signature request or process. Mobile certificates are linked to the user and its token registered on OpenOTP Token application. If the token is removed, the mobile certificate is also removed. These certificates have a short validity period (1 month) and are automatically issued through the Rsignd service.

Revoke Mobile certificate

The revocation process remains the same as client and server certificates.
mobile certificates are stored in the Certificate table of the SQL database. To revoke a mobile certificate, it must be retained in the SQL database and flagged as disabled by switching the enabled radio button. It is important to keep it in the database until its expiration; otherwise, the OCSP and CRL services will not provide information about the revocation. The revocation status can be removed by selecting the radio button, which makes the certificate reusable.
A valid certificate that has been removed from the database will be automatically re-added to the SQL database if re-used for signing purposes.

Other Certificate (based on custom CSR)

Purposes

Starting with WebADM 2.3.19, you can manually issue your Certificate Signing Request (CSR) with the desired Extended Key Usage (EKU) and certificate attributes using OpenSSL. You can submit the CSR directly through the WebADM Administrator Portal. This allow you entire customization and controls on certificate purposes. These certificate can not be included in auto-renewal process.

Issue other certificate

Once your CSR has been issued, log in to the WebADM Administrator Portal, click on the Admin tab, and then click on Sign External Certificate Request.

On the next page, either import your CSR file or paste the content of your CSR in PEM format into the provided text box.

Then, click on the corresponding Sign Certificate Request Data button according to the method you chose.

The certificate is now issued and can be downloaded. It is visible in the WebADM Database Viewer under Client, Server, and Mobile Certificates. This certificate type is flagged as OTHER in the SQL database.

Revoke other certificate

The revocation process remains the same as client, server or mobile certificates.
Other certificates are stored in the Certificate table of the SQL database. To revoke an Other certificate type, it must be retained in the SQL database and flagged as disabled by switching the enabled radio button. It is important to keep it in the database until its expiration; otherwise, the OCSP and CRL services will not provide information about the revocation.

You can remove the revocation status by selecting the radio button, which will make the certificate valid again at the OCSP and CRL levels.

Manager API Example

Using the Manager API for issuing a certificate is straightforward. You must use a super_admin account or an other_admin account with the necessary roles, and submit the CSR using the Sign_Certificate_Request method.
Below is the detail of that mehod:

For more information on using the Manager API, refer to the Manager API documentation.

Here is a PHP example:

<?php
$method = 'Sign_Certificate_Request';
$params = array(
    'request' => '-----BEGIN CERTIFICATE REQUEST-----
MIIC9zCCAd8CAQAwdTELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVRleGFzMRQwEgYD
VQQHDAtTYW4gQW50b25pbzEeMBwGA1UECgwVUkNEZXZzIERvY3VzbWVudGF0aW9u
MQswCQYDVQQLDAJJVDETMBEGA1UEAwwKQVBJIFRlc3RlcjCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANwMQFvzAv0fSUeH7wknzpWDfCR70RYPdqK+Mfex
l5+MYZbU4u9QNquPtwafdfbOrf1jam5aiWq7iKMWYu2506Kk/uCiJfhP5s1mhME0
/q4hh6i8PoRnYm+QSwxpnvK90iXG++flFhYVOqOWSoIvJ8R4kZ0nUasqRH4KKn5q
sqf0SNKYn3KFhaQieAYMcAoTbEg0uppFpq124dDOfr2ePlgo+/56mt8IUg2wW2yU
54j83yRpfL38sElDOcFUr08qfYPViYaits2IRLY/JSaL+ZseiKw5o8Kc1w8Sa/dV
HTRGxaaBxFoM8KAoSXCMdvf3W4DhYVj1qMSAbhlcShJt0TECAwEAAaA9MDsGCSqG
SIb3DQEJDjEuMCwwKgYDVR0RBCMwIYIKQVBJIFRlc3RlcoITdGVzdC5yY2RldnNk
b2NzLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAgvrd+vBnRwC/kqJA+qFCkmp3rW9+
+v/3WjUM8xKeDV4RJvC1NMo6yq5qKhi0Mbx8EK12jVIzRW9Mu4Q57pZLS7Drsvus
pEKpB2GMpbcl3kcN1dl6Hga6UnmUfIyo3CRJxcij9xgSCMhpJBLxoNIf+Dp1sReW
BWabKZPIBHv9bxLTAL6GYVbG28p9s48jPTwTzwcqpek+DR8pCn6SE1Ud7B4wcZNl
pSbIQN0hI7WzzZ/4JydmhO1H3iJMi/4I7Twfo0s7ePt7JaFDDSb+8SI+uwUsM7Ry
B1z7AzLv3GXz/TweJHcHxhpJN3XgIkAVlTFjk81LQyal72VExprqRzahkg==
-----END CERTIFICATE REQUEST-----'
);

$request = array(
    'jsonrpc' => "2.0",
    'method' => $method,
    'params' => $params,
    'id' => 0
);

$json = json_encode($request);

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://webadm1.rcdevsdocs.com/manag/");
curl_setopt($ch, CURLOPT_USERPWD, "CN=Administrator,CN=Users,DC=rcdevsdocs,DC=com:password");
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Connection: close"));
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $json);
$out = curl_exec($ch);
if ($out === false) {
    echo 'cURL Error: ' . curl_error($ch);
} else {
    print_r(json_decode($out));
}

curl_close($ch);
?>

Which is returning the following result and contains the signed certificate:

stdClass Object
(
    [jsonrpc] => 2.0
    [result] => -----BEGIN CERTIFICATE-----
MIIFPzCCAyegAwIBAgIRAN22D+9h4usma9wX3wnlhMYwDQYJKoZIhvcNAQELBQAw
UjEXMBUGA1UEAwwOUkNEZXZzIERvY3MgQ0ExCzAJBgNVBAsMAkNBMR0wGwYDVQQK
DBRSQ0RldnMgRG9jdW1lbnRhdGlvbjELMAkGA1UEBhMCTFUwHhcNMjQwODA1MTUx
NjE4WhcNMjUwODA1MTUxNjE4WjB0MQswCQYDVQQGEwJVUzEOMAwGA1UECAwFVGV4
YXMxFDASBgNVBAcMC1NhbiBBbnRvbmlvMR0wGwYDVQQKDBRSQ0RldnMgRG9jdW1l
bnRhdGlvbjELMAkGA1UECwwCSVQxEzARBgNVBAMMCkFQSSBUZXN0ZXIwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCuULYdF9uonJzNC1NdQ8DG0OlzAwVh
XbIB6AFKGnOxeAzI5yQuHJ7ziKZObH1z+hKCJ29klGcuhBUEsJgYENgAM2S4yk4Z
nF91Juuwx9F7etJGZJYSyrjBXGcf2Vde/6kFjmVE8ikzZC442Tk6f5L3NYhVFaTx
09hFJn/Cey8LeRq7sIuXHZcsNNsmSRn61iDCq2kxytnMYjUPsNBSVHYms+TH7hKU
TjeB9Yr814chD6FdfuErCdmQ5S7iuCvm7N9e/JnP6xyfV5Dlm7Fqs1Nwdd8aH7wM
uzHx5Rhm2nzFrbOfsvhlWFqraLZ+HizX6z2YaJjpXiMRsH0iq0mM71gNAgMBAAGj
ge0wgeowKgYDVR0RBCMwIYIKQVBJIFRlc3RlcoITdGVzdC5yY2RldnNkb2NzLmNv
bTB1BggrBgEFBQcBAQRpMGcwKwYIKwYBBQUHMAGGH2h0dHA6Ly9pYW0ucmNkZXZz
ZG9jcy5jb20vb2NzcC8wOAYIKwYBBQUHMAKGLGh0dHA6Ly9pYW0ucmNkZXZzZG9j
cy5jb20vY2FjZXJ0Lz9mb3JtYXQ9ZGVyMC8GA1UdHwQoMCYwJKAioCCGHmh0dHA6
Ly9pYW0ucmNkZXZzZG9jcy5jb20vY3JsLzAUBgsrBgEEAYKOOQMBAQQFT1RIRVIw
DQYJKoZIhvcNAQELBQADggIBAIyATL/haepxfGPc3pZXYbMPWfafBFPNBVVP8HIE
Zi7i2qmHAhgismd1gdVvC9mCYxr7mU20qcWon0X2Yq23/bUkaeZ/N7CE3hZQAWR5
GsJUTDvotlIyaLoIieu9ZUjM2cktwnuzkKnD3kD96IpcBRGgjZ+LY2Pu1f3hasX2
HxrLuB/7v1YBNdln93F7JjBR4h4vT7SN6KTdM6J+L7MA/S5RhYQxJs4bp2u81Zhb
jnpCxhvPNeYxSkNOlnNHP4hWu/zmfA16JTnAhNtoV9jveMnqoahYdOtE93TqIGGg
qO5AmFEN+XmDZPuU2ScldsX9WTnAnHq0AANAkUTYOO5o6vMR4/pCLpAWFYDc5ylw
idtyGkKM4eBIWKXPVhKLAE9SKpqN7RnucRyWxanzV+8isJSMTItuzoCKmoBdzGpk
0XDRxKy2gYoa0FSL9G/ib6NorTNCrivCHDcdPN1jBWM4LeYvbrU3fLsor9w69WV0
FsCUdgXO6mFquSPcwqQjdmEESOdBLbMLyFrTHzL0JjY5vgqkRRXBVdb1AfRqgUc+
4e7TZ37x0pmZKtT5ynhtFaADOT3KtUrcX4BLGf3UY45Mb95BcoC88Owm8ekZtBPy
myHnSD+YDAjMLy6e4QVCotRineOolQ3K1mL9+K6fgna+vv+FK3gac2WM+n3imFdE
nLIc
-----END CERTIFICATE-----
    [id] => 0
)