Certificate-based RADIUS Authentication Issue - External Windows CA vs. Internal WebADM CA

[Roland Schnabl]

Dear RCDevs Support Team,

I am currently setting up RADIUS EAP-TLS authentication and encountered a specific behavior regarding identity matching when using an external Windows CA compared to the internal WebADM Sub-CA.

The Scenario:
Our environment uses a Windows Root CA, and WebADM acts as a Sub-CA.

• Success: Using a client certificate issued by the WebADM Sub-CA works perfectly. The RADIUS User-Name (including the host/ prefix) is accepted.
• Issue: Using a client certificate issued by the Windows Root CA leads to an abort. The logs show: Request username not matching OpenOTP response.

Comparison of Logs:
In both cases, the NAS sends the User-Name as host/[Hostname].

1. Working (WebADM-CA):
   User-Name = "host/DESKTOP-V6KUI72" / CN = "DESKTOP-V6KUI72"
   Result: OpenOTP PKI login succeeded (Authentication continues).
2. Failing (Windows-CA):
   User-Name = "host/test01.firma.de  " / CN = "test01.firma.de"
   Result: OpenOTP PKI login succeeded -> Request username not matching OpenOTP response.

Questions & Documentation Request:

1. Identity Mapping: How can I configure OpenOTP to ignore or strip the host/ prefix during the name comparison for external certificates?
2. Windows CA Extensions: Are there specific X509 Extensions or Extended Key Usages (EKUs) required for the Windows CA templates (e.g. Client Authentication, specific SAN OIDs) to be fully compatible with the OpenOTP PKI login?
3. Documentation: Is there a comprehensive guide for this "Hybrid CA" setup (External Root -> WebADM Sub) and the required certificate attributes?

We would appreciate any technical documentation or guidance you can provide to resolve this naming mismatch.

Best regards,

Roland

[Yoann Traut (RCDevs)]

Hello,

A client certificate issued by a Windows CA can only be used if the corresponding computer object in Active Directory is activated (OpenOTP licensed).

If you use the RCDevs CA, the client certificate is stored in the WebADM SQL database, and no OpenOTP license is required for this use case.

The username mismatch issue has been reproduced on our side, and there is nothing that can be done at your level to resolve it. We will coordinate with the development team to address the problem.

Regards

[Roland Schnabl]

Hello Yoann,

Thank you for the clarification regarding the licensing and the confirmation of the username mismatch bug.

In the meantime, I have tried to implement a workaround by using a PowerShell script to issue certificates directly via the WebADM API (using the internal RCDevs CA). This would resolve the mismatch issue and the licensing requirement you mentioned.

The Problem with the API:
I am currently unable to successfully request a "Client" type certificate via the API. Regardless of the parameters I send, the issued certificate is always categorized as type "OTHER" in WebADM.
As you know, a certificate typed as "OTHER" cannot be used for EAP-TLS client authentication in this context.

Request:

1. Documentation/Fix: Could you please provide the exact API parameter or metadata required to force the certificate type to "Client"? My current script (attached) does not seem to trigger the correct type assignment.
2. API Extension: If this is a limitation of the current API version, would it be possible to include a fix or an extension for this in the upcoming development cycle alongside the username mismatch fix?

A working API for automated client certificate issuance would be a significant help for our deployment. I have attached my script for your review.

Looking forward to your technical feedback.

Best regards,

Roland

[Yoann Traut (RCDevs)]

Hello,

There is a simple endpoint that can be called to issue a certificate for EAP-TLS authentication:

https://${fromServer}/mycert/${role}/${hostname}/${PRODUCT_NAME,,}

E.g : 

curl https://webadm1.rcdevsdocs.com/mycert/client/DESKTOPXX/openotp > /tmp/test.crt

The certificate request must then be approved in the WebADM GUI. Once approved, the corresponding SQL entry is created automatically, and the test.crt file will contain both the certificate and the private key. That certificate will be flagged as specified in the request : CLIENT.

If you don't want any interaction with the admin portal, then you can set the API in auto-approval mode but it is only in auto-approval mode for a specific period.

WebADM GUI > Admin > Create Client / Server Certificate > Auto Confirm Mode 

Alternatively, you can generate your own CSR and private key, then submit the CSR through the WebADM Manager API using the method described here:

https://docs.rcdevs.com/webadm-sign_certificate_request/

The certificate stored in SQL is currently marked as OTHER instead of CLIENT. In principle, it should be usable with PKI login, but this does not appear to be the case at the moment. 

I will confirm if this behavior is intended with the development team and will get back to you.

Regards,

[Roland Schnabl]

Hello Yoann,

Thank you for the information regarding the /mycert/ endpoint and for checking the "OTHER" vs "CLIENT" type issue with the development team. I will adjust my automation accordingly.

New Issue: Missing RADIUS Reply Attributes (VLAN assignment)
Now that the certificate authentication (PKI Login) is working correctly, I am facing an issue with VLAN assignment via RADIUS attributes.

Current State:

• The authentication is successful: OpenOTP PKI login succeeded.
• The Client Policy is correctly enforced: 802.1X Computer (matched client ID).
• The computer object is a member of an AD group where I have configured the "RADIUS Reply Attributes" as follows:
  • Tunnel-Type = 13
  • Tunnel-Medium-Type = 6
  • Tunnel-Private-Group-ID = XXX

The Problem:
Although the policy is valid, the RADIUS server does not include these VLAN attributes in the final Access-Accept packet. The attributes seem to be ignored or not fetched from the AD group.

Questions:

1. Is there a specific setting required in the Radius Bridge or the Client Policy to ensure that group-based RADIUS attributes are merged into the response for computer accounts?
2. Do I need to enable a specific "Search Mode" or "Attribute Mapping" in WebADM to look up the group memberships of the computer object during the EAP-TLS flow?
3. Is there a clear documentation on how RADIUS attributes are inherited from AD groups specifically for machine authentication?

I would appreciate your guidance on how to make the VLAN assignment dynamic based on the computer's group membership.

Best regards,

[Yoann Traut (RCDevs)]

Hello,

There are two possibilities:

1. The certificate is issued and stored on the computer object (through AD CA or WebADM CA, which requires an OpenOTP license for authentication).
   In this scenario, the RADIUS AVP can be configured on the group to which the computer belongs, or directly on the computer object itself.

Please see the attached screenshots.

Logs : 

[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] New openotpPKILogin SOAP request
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] > Certificate: 2105 Bytes
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] > Client ID: Wifi
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] > Options: RADIUS,NAC
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] > Context: 42eb8ab2f978@Wireless
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Enforcing client policy: Wifi (matched client ID)
[2026-02-17 10:00:44] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Registered openotpPKILogin request
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Resolved LDAP user: CN=DOCWIN11,CN=Computers,DC=rcdevsdocs,DC=com (route #00)
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Resolved LDAP groups: ComputerGrp (route #00)
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Started transaction lock for user
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Found user fullname: DOCWIN11
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Found 13 user settings: EnableLogin=Yes,SelfRegister=Yes,OfflineExpire=30,ReplyData=[1 Items],MobileTimeout=30
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Returning 1 RADIUS reply attributes
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Updated user data
[2026-02-17 10:00:45] [192.168.3.166:62962] [OpenOTP:JPLJ2Y9W] Sent login success response

2. If you are using client certificates stored in SQL, the certificate must include the RADIUS AVP.

In this scenario, it is unlikely that the AVP can be added through an automated script, as the RADIUS AVP can only be configured via the client certificate issuance form. (screenshots attached)

Logs : 

[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] New openotpPKILogin SOAP request
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] > Certificate: 1983 Bytes
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] > Client ID: Wifi
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] > Options: RADIUS,NAC
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] > Context: 42eb8ab2f978@Wireless
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] Enforcing client policy: Wifi (matched client ID)
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] Registered openotpPKILogin request
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] Returning 1 RADIUS reply attributes
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] Updated MAC address information
[2026-02-17 10:09:30] [192.168.3.166:63058] [OpenOTP:VL4R0DXB] Sent login success response

Regards

[Roland Schnabl]

Dear Yoann,

Thank you for your detailed technical explanation. However, I must express my serious concern regarding the licensing and communication of your product’s capabilities.

1. Licensing Inconsistency & Communication:
The information provided in your offer and on your website was not clear. We chose RCDevs specifically as a European company because we expected transparent communication.

• We were told that using the RCDevs CA does not require an OpenOTP license for client certificates.
• However, your recent explanation reveals that if we use this "license-free" path, we lose the ability to assign dynamic RADIUS attributes (VLANs) via AD groups, which is a core requirement for any NAC/802.1X setup.
• If we want the RADIUS attributes to work via AD groups, we are forced to license the computer objects as full users.

This feels like a contradiction. Stating that certificates are "license-free" while simultaneously stripping away the essential RADIUS functionality unless a license is purchased is, in my opinion, misleading.

2. Bug Fix for Windows CA / External Certificates:
Since the license-free "SQL-stored certificate" path is too limited for our production needs (due to the lack of automated AVP assignment), we are dependent on the fix for the Windows CA identity mismatch you identified earlier.

• What is the estimated Time of Arrival (ETA) for this fix? We need a working solution..

3. Commercial Negotiation:
Given the misleading communication regarding the necessity of licenses for computer accounts to achieve basic VLAN assignment, we need to discuss a commercial solution.

• We are prepared to discuss additional licenses for our computer accounts, but we do not see it as justified to pay the full user license fee for a machine account that only performs EAP-TLS.

Please provide a status update on the bug fix and a proposal on how to resolve this licensing discrepancy in a fair manner.

Best regards,

[Yoann Traut (RCDevs)]

Hello,

We are currently reviewing the available options with the development team and will get back to you as soon as we have further updates.

At this stage, they have agreed to enhance the Manager API methods so that you can script and dynamically pass the RADIUS attributes during certificate issuance for script execution. We will also verify whether a similar approach can be implemented through the /mycert/ endpoint.

Regarding OpenOTP licensing for computer objects, we are assessing how this can be managed on our side.

Regarding the mismatch username topic, we will have a version fixing this in the coming days on next week.

I noticed that you have an Enterprise License. You may also contact us via the support email address to open a ticket, which will help us track and follow up on this topic more efficiently.

Regards,

[Yoann Traut (RCDevs)]

Hello Roland,

To keep you updated on your request: we have adapted the Manager API method to allow certificate signing.

The method now supports issuing CLIENT type certificates and adding RADIUS attributes to the certificate.

These certificates will be stored in SQL and will not consume any user license for the EAP-TLS computer authentication use case. That will allow you to script the deployment.

Here is how it works : 

- Issue a CSR and it's key with OpenSSL. 

- Submit the CSR to WebADM Manager API, method Sign_Certificate_Request
As parameter of this method, you will found, expires for cert expiration, altname, type (CLIENT or SERVER), radius (for radius AVP)

Here is a PHP example :

<?php

$method = 'Sign_Certificate_Request';

$params = array(

'request' => '-----BEGIN CERTIFICATE REQUEST-----

MIIFUDCCAzgCAQAwgbExCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh

MRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMRMwEQYDVQQKDApNeSBDb21wYW55MRYw

FAYDVQQLDA1JVCBEZXBhcnRtZW50MSUwIwYDVQQDDBx3aW4xMV9DTl9jb25mLnJj

ZGV2c2RvY3MuY29tMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBteWRvbWFpbi5jb20w

ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDuKWty/A1cBKXrCKjyFwH1

rwZDgkkAZumamZDzYqxYsm1m6oQxn7LMgHK46TLvH4GXBiVkWyDqLkpoN1IPISWo

By+G/Nsu/NKzOgFNY2vgfcHjH9MWpAMT4gUGPFTY2vE+xJsyah/yQ43d6rnwLCbO

As/5hMsH9wAZZ6BX+MLWSh6Yktlkstm0FfnGZr73XStHoOytRjlXF4rOVdcUJujs

pT/K2H7j1k1V+HenvCozM6efirSPhPZb51Cj3bWSsPevXDpPNYuml88Sc8ljy1JS

18rF5a6cTIMavBRBHCRqaw+mTY6ilk0jGjjpsP1MrxTC+CrpZLWLtG/MdlqdYXbv

1+9UWU+clgm9CptinwoPED1rtplG97GweRbngZxTcZ0mzUSbhxNHqkx/6ALPVQFV

QBiiQ55RfjjO5SWdYW0RDM84z3/yhohRAQnBjUlGHZag2r/yvvjvM+2Za0Zvmokd

7aCdT0ZAr1sN4JEtwnMkVHZs/WfX/VsNFmKy+bLBB/STjpgDGasECvPoMwW28VY4

CgBcY6+GnFEarQZh4gMZ3uXY3x4ZbugQA3dd/6YVZxr+egVYcM7SwZgi60Zk1TI7

nU+IPO2c5BmlXFehcSYEG15Sh1/uAWoIUv7TfPurUNXX+NqSBtZbpR4uIB3O9XhI

0N8XE+1jJHltZQTvrRs5dwIDAQABoFkwVwYJKoZIhvcNAQkOMUowSDAXBgsrBgEE

AYKOOQMBAQQIDAZDTElFTlQwLQYDVR0RBCYwJIILZXhhbXBsZS5jb22CD3d3dy5l

eGFtcGxlLmNvbYcEwKgBCjANBgkqhkiG9w0BAQsFAAOCAgEA5gmL/conPRaf+f2m

ewNI+W2lv4oux59OUMgKRh1wfXysyTd1+Vx/dxGymCo7NLUz5FFJm9j2Okuz8bM3

lKh+wBHOAvc0xqJyK75us6IZ5PSFPnaNi53/4OvAVoDsNWd45hlfEhjfnuRU9gsL

zZDy+7Ibg+AKVfcNMO31zEluaILVP6Ipgc3WNVJYRBot4OD8MIqrG3tds5MJ0zLR

mBepejmnxOUQMWDeLDp5U+JlCcM2X5MPtW8QdpL6u4sz6LnH/gNp5dufHRFUDBtU

RA9GLJECkwkbCL1J0dWppOswSpSmAOkxcVN5PjfJ02Yoh0p3ZNUp3jcLJdjXwg5w

D+Mf1CS1ryEP8Z2vv37nSf16uEaTQckVxMZKaQRTRmNRCUhgjy6HVu1YvtB/w/M6

hERIovYc+FVFT6fgy2WRCKkB4NR71w/9uBdR7L7LS4ANiCypXffWVwjGtlCfd262

Ky/WVitIGuHxbT+MSPZBH5c5T+FBAGVaVQt4xf1FVWnyj9eImP7tUeeswTFHl6Pf

syNoe6j3t/mVgYIlGR3u971nakRiYBVI4ZkD27G3NNlWg0q00hgbIW54Ej5tyaV5

uTs/M1c3wZ3jP3BgBSyrUOguVRzKMvb8c2vCw7Zoue2DdWuwryTFVzp+J3y1raun

eZk5wSwD76vZQDx2ZjEQv2DVn5k=

-----END CERTIFICATE REQUEST-----',

'expires' => '365',

'altname' => 'host_alternative_name',

'type' => 'CLIENT',

'radius' => 'ASA:ASA-VLAN=1,SPLUNK:ASA-VLAN=2'

);

$request = array(

'jsonrpc' => "2.0",

'method' => $method,

'params' => $params,

'id' => 0

);

$json = json_encode($request);

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, "https://192.168.4.160/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);

?>

Then if the call succeed, you will receive the certificate signed as response and the certificate will be stored in SQL : 

stdClass Object

(

[jsonrpc] => 2.0

[result] => -----BEGIN CERTIFICATE-----

MIIHGjCCBQKgAwIBAgIRAPDSKegIK3ZeY9Gy+ihGJQAwDQYJKoZIhvcNAQELBQAw

UjEXMBUGA1UEAwwOUkNEZXZzIERvY3MgQ0ExCzAJBgNVBAsMAkNBMR0wGwYDVQQK

DBRSQ0RldnMgRG9jdW1lbnRhdGlvbjELMAkGA1UEBhMCTFUwHhcNMjYwMjI2MDcz

OTUwWhcNMjcwMjI2MDczOTUwWjCBsTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh

bGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xEzARBgNVBAoMCk15IENv

bXBhbnkxFjAUBgNVBAsMDUlUIERlcGFydG1lbnQxJTAjBgNVBAMMHHdpbjExX0NO

X2NvbmYucmNkZXZzZG9jcy5jb20xITAfBgkqhkiG9w0BCQEWEmFkbWluQG15ZG9t

YWluLmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO4pa3L8DVwE

pesIqPIXAfWvBkOCSQBm6ZqZkPNirFiybWbqhDGfssyAcrjpMu8fgZcGJWRbIOou

Smg3Ug8hJagHL4b82y780rM6AU1ja+B9weMf0xakAxPiBQY8VNja8T7EmzJqH/JD

jd3qufAsJs4Cz/mEywf3ABlnoFf4wtZKHpiS2WSy2bQV+cZmvvddK0eg7K1GOVcX

is5V1xQm6OylP8rYfuPWTVX4d6e8KjMzp5+KtI+E9lvnUKPdtZKw969cOk81i6aX

zxJzyWPLUlLXysXlrpxMgxq8FEEcJGprD6ZNjqKWTSMaOOmw/UyvFML4KulktYu0

b8x2Wp1hdu/X71RZT5yWCb0Km2KfCg8QPWu2mUb3sbB5FueBnFNxnSbNRJuHE0eq

TH/oAs9VAVVAGKJDnlF+OM7lJZ1hbREMzzjPf/KGiFEBCcGNSUYdlqDav/K++O8z

7ZlrRm+aiR3toJ1PRkCvWw3gkS3CcyRUdmz9Z9f9Ww0WYrL5ssEH9JOOmAMZqwQK

8+gzBbbxVjgKAFxjr4acURqtBmHiAxne5djfHhlu6BADd13/phVnGv56BVhwztLB

mCLrRmTVMjudT4g87ZzkGaVcV6FxJgQbXlKHX+4BaghS/tN8+6tQ1df42pIG1lul

Hi4gHc71eEjQ3xcT7WMkeW1lBO+tGzl3AgMBAAGjggGJMIIBhTALBgNVHQ8EBAMC

BeAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU/v4hVYQppxzLg2Ic

nUkTPxgGHRUwIAYDVR0RBBkwF4IVaG9zdF9hbHRlcm5hdGl2ZV9uYW1lMIGVBggr

BgEFBQcBAQSBiDCBhTBHBggrBgEFBQcwAoY7aHR0cDovL2Nsb3VkLnJjZGV2cy5j

b20vY2EvNXdzZ2p2YmhpM2w1aS9jYWNlcnQvP2Zvcm1hdD1kZXIwOgYIKwYBBQUH

MAGGLmh0dHA6Ly9jbG91ZC5yY2RldnMuY29tL2NhLzV3c2dqdmJoaTNsNWkvb2Nz

cC8wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL2Nsb3VkLnJjZGV2cy5jb20vY2Ev

NXdzZ2p2YmhpM2w1aS9jcmwvMBUGCysGAQQBgo45AwEBBAZDTElFTlQwLwYLKwYB

BAGCjjkDAQIEIEFTQTpBU0EtVkxBTj0xLFNQTFVOSzpBU0EtVkxBTj0yMA0GCSqG

SIb3DQEBCwUAA4ICAQA0cEreqk5CG6UivkAZO2gumeN1MfoAO8EE71N5RraStKFH

Mi5UJi5BoBXbTLz5CqFqt6ijnsKZbR3MQGhyjuMqNR/nfWLVC3ZGpCjNlziuHo+i

Fib/W09UE+kiaUWFMD/6Pm3Gr3dOPqtGba8sRZwwIphPwdKJravLmDtA3YyDdmru

8ZIdN5rDO8XVA2RBb33oCjWtv+JRX7HrY/fv8DlHPXAxdXTZeHivNEKLtryGMzqS

dxA3q///w1tmW8Jo+WUbrF1TbGJuSitz6Ywh+D4oiVWqqvVsE3Ug9rLW2AUv8iFy

Xn29Tm7dy1M7/H3cfMEYrPQ6Q//BJ/ocoDDHjk+8QrqaJhrCxjFeIJ5TVNRqRpBl

/N64PV1tma16PkGQL3q3kyJQg9u8nVJ/IphH30JiHtwpz884HStRcYlEAtVDFHRB

U7m5XvnHriQL8ArV3bGCCnjvNm9W/Enmgk6aftWA5F+edXy3Rdjx/zP12r7EyfS4

dZ5M1x4xJ/nAbsjwKu/GrqMpZrY+y28l5yoZGDiZbN6HBs6sfeQYFOrlbMDmLk6U

ynKQ1/iSCCTq9YhWrbzHad9FgcaeQRO09FKVds/h1gUyjF3ohNavfHozLJtPAFDR

xEFW9/kNfHFsZpOZdgccSjPso4tWfuv1KmJgSkofhXoldFvUV9+IF/977hOChA==

-----END CERTIFICATE-----

[id] => 0

)

If you check the content of the certificate, you will see our custom OID :

1.3.6.1.4.1.34617.3.1.1:

CLIENT

1.3.6.1.4.1.34617.3.1.2:

ASA:ASA-VLAN=1,SPLUNK:ASA-VLAN=2

You now need to build a .p12 or .pfx file containing both the certificate and the private key in order to import it into Windows. This step may be optional, as I am not fully certain whether Windows allows importing the certificate and private key separately.

The version including this improvement is not yet available, but it will be released soon in our repository (WebADM 2.4.15-1).

I am also confirming one additional point with the development team regarding restricting the certificate usage to a specific application (OpenOTP or Spankey). An additional parameter may be introduced in the method, such as "application", to enforce this restriction.

Hope this help.

If you have any questions, please let me know.

Regards

[Yoann Traut (RCDevs)]

Final version:

• AlternativeNames cannot be passed through the CSR. If included in the CSR, they will be removed from the signed certificate. They must be explicitly provided as a parameter in the API call.

• AlternativeNames can only be added with SERVER type.

• Application can only be added with CLIENT type.

• Attributes can only be added with CLIENT type.

e.g for a client cert : 

'expires' => '365',

'type' => 'CLIENT',

'attributes' => 'ASA:ASA-VLAN=1,Tunnel-Type=0',

'application' => 'OpenOTP'

e.g for a client server cert :

'expires' => '365',

'type' => 'SERVER',

'altnames' => 'hostname1,hostname2'

Method description attached in screenshot.

Regards