802.1x wired based authentication using certificates. NPS rejection.

[eamkhal]

Describe the Bug

Hi, I am using 2 tier PKI infrastructure where we have both PKIRootCA and PKISubCA. I am running Network policy server on windows server 2022 for authentication. I have the supplicant machine running on Ubtunu version 24.04.1 LTS. There is a fibrolan switch which acts as an authenticator and connects both supplicant and authentication server which is in our case is Microsoft server 2022.
I generated 2 certificates for client (ubuntu) and server (windows server 2022). I then installed complete chain of certificate in PK7 format on server and installed specific rootCA certificate in trusted zone and subCA certificate in intermediate certificate authority.
On those certificate, I just defined CN name for both server and client which I have configured the hostname. Eg. the server NPS server hostname is radius.testbed.local which is also a domain controller (testbed.local) and the client has CN name (dot1x-thinkpad) and thats the CN for the client I have defined in the client certificate.

I tried my level best to get this sorted but couldn't and finally raised a ticket to Microsoft support and they checked server configuration and found no issue there and ask me to contact EJBCA since there might be an issue with the certificate. The certificates are valid and there is no timestamp mismatch during client request.

Client configuration:

oot@dot1x-Thinkpad:/home/user1# cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
root@dot1x-Thinkpad:/home/user1# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ap_scan=0
fast_reauth=1

network={
key_mgmt=IEEE8021X
eap=TLS
identity="user1"
ca_cert="/etc/ssl/certs/ejbca_combined.pem"
client_cert="/etc/ssl/certs/ejbca_client.pem"
private_key="/etc/ssl/private/ejbca_client.key"

}

Client certificate, ejbca_client.pem

oot@dot1x-Thinkpad:/home/user1# openssl x509 -in /etc/ssl/certs/ejbca_client.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
23:d6:e8:f5:d0:38:05:39:e9:5a:bd:b8:0b:81:dc:9b:d0:c2:a5:4d
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = DK, O = MTI, CN = My PKI Sub CA-G1
Validity
Not Before: Nov 19 12:06:03 2024 GMT
Not After : Nov 19 12:06:02 2026 GMT
Subject: C = DK, O = MTI, CN = dot1x-Thinkpad
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:b2:9f:4b:0b:dd:21:f0:78:bd:98:ef:35:11:ea:
a9:4c:dc:a0:a3:0b:80:da:55:81:b3:7e:19:52:52:
34:a7:5d:49:17:79:12:23:b4:a5:1e:83:6c:89:6a:
d7:58:43:2a:a9:b3:f7:fb:68:3e:94:3a:dd:4f:fc:
85:ca:a9:c1:52
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
FA:53:57:3A:25:36:A6:0A:47:FD:82:32:FD:7C:91:00:0F:56:41:E7
Authority Information Access:
OCSP - URI:http://172.17.21.65/ejbca/publicweb/status/ocsp
X509v3 Subject Alternative Name:
DNS:dot1x-Thinkpad.testbed.local
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://172.17.21.65/ejbca/publicweb/crls/search.cgi?iHash=yH60vQBhFFlXBTQ9T3Zv202E0UE CRL Issuer:
DirName:CN = My PKI Sub CA-G1, O = MTI, C = DK
X509v3 Subject Key Identifier:
FD:64:C4:2B:7A:17:17:AF:8A:45:94:BB:A2:DD:E5:FA:F0:6A:D3:F9
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:44:02:20:28:f6:9e:f3:4b:9a:c5:9b:80:42:5f:f1:fa:fb:
7b:ce:27:e2:16:d3:cf:c8:5a:a3:be:26:99:5b:c2:38:85:85:
02:20:40:60:e5:e4:99:51:58:0c:f3:ba:8f:7a:9e:61:8d:89:
29:7e:38:88:cb:7d:3d:f5:b6:27:a7:ad:32:06:8b:9d

ejbca_combined.pem

oot@dot1x-Thinkpad:/home/user1# openssl x509 -in /etc/ssl/certs/ejbca_combined.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2d:e6:53:2f:70:93:8a:3f:be:be:0b:43:19:2f:6a:69:3b:f6:d5:f1
Signature Algorithm: ecdsa-with-SHA512
Issuer: C = DK, O = MTI, CN = My PKI Root CA-G1
Validity
Not Before: Oct 16 09:20:09 2024 GMT
Not After : Oct 13 09:20:08 2039 GMT
Subject: C = DK, O = MTI, CN = My PKI Sub CA-G1
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:21:57:16:ec:0e:44:8b:a9:69:3e:5c:46:c7:8e:
e6:69:e7:c7:2d:18:27:a5:b3:c2:05:b1:ad:55:6b:
da:42:16:83:6d:3e:d8:8c:d4:44:7f:47:bd:b4:63:
f0:f1:87:57:43:84:44:69:8a:a3:75:6c:8a:27:c3:
0e:28:70:04:0a
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Authority Key Identifier:
49:DB:30:2F:42:6F:C1:51:98:D9:73:D4:25:27:62:E0:02:E2:83:D1
X509v3 CRL Distribution Points:
Full Name:
URI:http://172.17.21.65/ejbca/publicweb/crls/search.cgi?iHash=yH60vQBhFFlXBTQ9T3Zv202E0UE CRL Issuer:
DirName:CN = MyPKISubCA-G1, O = MTI, C = DK
X509v3 Subject Key Identifier:
FA:53:57:3A:25:36:A6:0A:47:FD:82:32:FD:7C:91:00:0F:56:41:E7
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA512
Signature Value:
30:45:02:21:00:c2:d6:6d:bf:93:21:4d:72:b0:cf:7b:23:03:
82:80:ad:a7:2e:51:6b:12:81:26:7e:c0:e7:24:64:e0:0d:54:
a2:02:20:12:2b:1d:08:24:88:f7:0e:12:92:f7:44:7a:07:3f:
94:b6:e7:04:0d:94:ff:76:ad:2c:1e:84:5f:88:42:d3:61

To Reproduce

Expected Behavior

NPS server should approve the request coming from client since it has the valid certificate.

Screenshots and Logs




![image](https://github.com/user-attachments/assets/8b34a212-759f-4198-be66-d085de754e83

Product Deployment

Please complete the following information:

• Deployment format: [e.g. software, container]
• Version [e.g. 8.0.0]

Desktop

Please complete the following information:

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional Context

Add any other context about the problem here.

[primetomas]

All you can see there is the error message that one of the CAs is not trusted. You have added the Root CA as a root, but aren't there also trust flags what it can be trusted for?
I am not familiar with Windows Server, so that's the best I can say unfortunately. Troubleshooting windows environments can be tricky, we have documented some steps for auto-enrollment here.
https://docs.keyfactor.com/ejbca/latest/microsoft-auto-enrollment-troubleshooting

We have developed a small tool to troubleshoot windows auto enrollment, but not open source.

[eamkhal]

Hi Tomas,

As per Microsoft support team, there is something wrong in the certificates. Could you please clear a couple of my doubts:

1. The server certificate which I installed on server 2022 has a CN and SAN values which I set according to their host name and fqdn names.
2. On client certificate which I installed on Ubuntu supplicant, it has also CN and SAN name which is also as per their hostname and DNS/fqdn name.
   Is this the right way?
   Also, the supplicant machine is not part of domain, should I also try to add user information in the certificate?

Thank you!
//Khalid

[primetomas]

How the DN and SANs are constructed is nothing technically wrong or right. That is up to the application requirements. Just like web browsers require the SAN to be the DNS/IP of the host or they will throw a warning, that is the web browser policy. Other applications have completely different requirements on DN/SAN. From that aspect it's Microsoft that need to tell you what DN/SAN the certificates should have, and you can make sure they have that.

Technically:

• You use ECDSA, and have Key Encipherment key usage. This is invalid, but I have never seen a client actually forbidding it in practice. ECDSA certificates should only have Digital Signature key usage.
• You use CRL Issuer in the CRL Distribution point, no-one does that. Remove it. The CRL Issuer in the Sub CA certificate is invalid as it has the Sub CA DN, but the Root CA issues the Sub CA certificate. Actually the whole CDP look invalid. Does the CRL Distribution point the Sub CA certificate point to the Sub CAs own CRL? The CDP in the SubCA certificate must point to the Root CAs CRL as the Root CA would revoke the Sub CA.

You don't display print the Root CA above, so I can't say anything about that.

[eamkhal]

Hi,
As per your suggestions, I changed CDP on MyPKISUBCA and point it to MyPKIRootCA. Please have a look at both client and server certificates:

oot@dot1x-Thinkpad:/usr/local/share/ca-certificates# openssl x509 -in /etc/ssl/certs/ejbca_client.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
77:94:07:a4:78:3a:81:9a:aa:0c:97:9e:36:82:42:fb:d8:d2:54:24
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = DK, O = MTI, CN = My PKI Sub CA-G1
Validity
Not Before: Dec 5 16:50:22 2024 GMT
Not After : Dec 5 16:50:21 2026 GMT
Subject: C = DK, O = MTI, CN = dot1x-Thinkpad
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:9d:c3:77:3d:01:a4:27:76:92:5f:d0:43:e8:1f:
47:60:ba:12:79:3e:cb:cf:f7:44:90:79:d1:0f:6a:
74:49:00:96:f6:a2:e8:2c:56:98:7d:5d:d5:21:eb:
f1:34:48:f9:ac:7d:ab:e3:5e:28:a5:3f:09:46:f8:
cb:69:8d:e6:0d
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
FA:53:57:3A:25:36:A6:0A:47:FD:82:32:FD:7C:91:00:0F:56:41:E7
Authority Information Access:
OCSP - URI:http://172.17.21.65/ejbca/publicweb/status/ocsp
X509v3 Subject Alternative Name:
DNS:dot1x-Thinkpad.testbed.local
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://172.17.21.65/ejbca/publicweb/crls/search.cgi?iHash=pmTlWoFwLTY/OG1B3U50KIneqzs CRL Issuer:
DirName:CN = My PKI Root CA-G1, O = MTI, C = DK
X509v3 Subject Key Identifier:
F4:26:55:DC:51:E8:C5:4E:C9:D2:C9:1C:85:45:EC:31:01:BB:01:AA
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:45:02:20:3e:a6:89:b5:92:6f:f2:22:5d:3d:30:01:7a:8d:
b4:6d:b3:57:1a:f2:72:b4:db:ce:e5:57:3d:5f:70:5e:2d:7c:
02:21:00:ae:dd:e7:93:e3:99:09:96:bb:41:e5:fa:71:3e:fd:
f0:27:74:f4:7f:3a:bb:42:56:e9:1b:eb:e3:6a:3a:59:b9
root@dot1x-Thinkpad:/usr/local/share/ca-certificates#

root@dot1x-Thinkpad:/usr/local/share/ca-certificates# openssl x509 -in /etc/ssl/certs/ejbca_combined.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2d:e6:53:2f:70:93:8a:3f:be:be:0b:43:19:2f:6a:69:3b:f6:d5:f1
Signature Algorithm: ecdsa-with-SHA512
Issuer: C = DK, O = MTI, CN = My PKI Root CA-G1
Validity
Not Before: Oct 16 09:20:09 2024 GMT
Not After : Oct 13 09:20:08 2039 GMT
Subject: C = DK, O = MTI, CN = My PKI Sub CA-G1
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:21:57:16:ec:0e:44:8b:a9:69:3e:5c:46:c7:8e:
e6:69:e7:c7:2d:18:27:a5:b3:c2:05:b1:ad:55:6b:
da:42:16:83:6d:3e:d8:8c:d4:44:7f:47:bd:b4:63:
f0:f1:87:57:43:84:44:69:8a:a3:75:6c:8a:27:c3:
0e:28:70:04:0a
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Authority Key Identifier:
49:DB:30:2F:42:6F:C1:51:98:D9:73:D4:25:27:62:E0:02:E2:83:D1
X509v3 CRL Distribution Points:
Full Name:
URI:http://172.17.21.65/ejbca/publicweb/crls/search.cgi?iHash=yH60vQBhFFlXBTQ9T3Zv202E0UE CRL Issuer:
DirName:CN = MyPKISubCA-G1, O = MTI, C = DK
X509v3 Subject Key Identifier:
FA:53:57:3A:25:36:A6:0A:47:FD:82:32:FD:7C:91:00:0F:56:41:E7
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA512
Signature Value:
30:45:02:21:00:c2:d6:6d:bf:93:21:4d:72:b0:cf:7b:23:03:
82:80:ad:a7:2e:51:6b:12:81:26:7e:c0:e7:24:64:e0:0d:54:
a2:02:20:12:2b:1d:08:24:88:f7:0e:12:92:f7:44:7a:07:3f:
94:b6:e7:04:0d:94:ff:76:ad:2c:1e:84:5f:88:42:d3:61

On the client machine, I combined both rootCA and Subca in the supplicant file and thats how it looks:

oot@dot1x-Thinkpad:/usr/local/share/ca-certificates# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ap_scan=0
fast_reauth=1

network={
key_mgmt=IEEE8021X
eap=TLS
identity="user1"
ca_cert="/etc/ssl/certs/ejbca_combined.pem"
client_cert="/etc/ssl/certs/ejbca_client.pem"
private_key="/etc/ssl/private/ejbca_client.key"

}
root@dot1x-Thinkpad:/usr/local/share/ca-certificates#

oot@dot1x-Thinkpad:/usr/local/share/ca-certificates# cat /etc/ssl/certs/ejbca_client.pem
-----BEGIN CERTIFICATE-----
MIIC9jCCApygAwIBAgIUd5QHpHg6gZqqDJeeNoJC+9jSVCQwCgYIKoZIzj0EAwIw
NjELMAkGA1UEBhMCREsxDDAKBgNVBAoMA01USTEZMBcGA1UEAwwQTXkgUEtJIFN1
YiBDQS1HMTAeFw0yNDEyMDUxNjUwMjJaFw0yNjEyMDUxNjUwMjFaMDQxCzAJBgNV
BAYTAkRLMQwwCgYDVQQKDANNVEkxFzAVBgNVBAMMDmRvdDF4LVRoaW5rcGFkMFkw
EwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEncN3PQGkJ3aSX9BD6B9HYLoSeT7Lz/dE
kHnRD2p0SQCW9qLoLFaYfV3VIevxNEj5rH2r414opT8JRvjLaY3mDaOCAYgwggGE
MB8GA1UdIwQYMBaAFPpTVzolNqYKR/2CMv18kQAPVkHnMEsGCCsGAQUFBwEBBD8w
PTA7BggrBgEFBQcwAYYvaHR0cDovLzE3Mi4xNy4yMS42NS9lamJjYS9wdWJsaWN3
ZWIvc3RhdHVzL29jc3AwJwYDVR0RBCAwHoIcZG90MXgtVGhpbmtwYWQudGVzdGJl
ZC5sb2NhbDATBgNVHSUEDDAKBggrBgEFBQcDAjCBpgYDVR0fBIGeMIGbMIGYoFmg
V4ZVaHR0cDovLzE3Mi4xNy4yMS42NS9lamJjYS9wdWJsaWN3ZWIvY3Jscy9zZWFy
Y2guY2dpP2lIYXNoPXBtVGxXb0Z3TFRZL09HMUIzVTUwS0luZXF6c6I7pDkwNzEa
MBgGA1UEAwwRTXkgUEtJIFJvb3QgQ0EtRzExDDAKBgNVBAoMA01USTELMAkGA1UE
BhMCREswHQYDVR0OBBYEFPQmVdxR6MVOydLJHIVF7DEBuwGqMA4GA1UdDwEB/wQE
AwIFoDAKBggqhkjOPQQDAgNIADBFAiA+pom1km/yIl09MAF6jbRts1ca8nK0287l
Vz1fcF4tfAIhAK7d55PjmQmWu0Hl+nE+/fAndPR/OrtCVukb6+NqOlm5
-----END CERTIFICATE-----

oot@dot1x-Thinkpad:/usr/local/share/ca-certificates# cat /etc/ssl/certs/ejbca_combined.pem
-----BEGIN CERTIFICATE-----
MIICfjCCAiSgAwIBAgIULeZTL3CTij++vgtDGS9qaTv21fEwCgYIKoZIzj0EAwQw
NzELMAkGA1UEBhMCREsxDDAKBgNVBAoMA01USTEaMBgGA1UEAwwRTXkgUEtJIFJv
b3QgQ0EtRzEwHhcNMjQxMDE2MDkyMDA5WhcNMzkxMDEzMDkyMDA4WjA2MQswCQYD
VQQGEwJESzEMMAoGA1UECgwDTVRJMRkwFwYDVQQDDBBNeSBQS0kgU3ViIENBLUcx
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEIVcW7A5Ei6lpPlxGx47maefHLRgn
pbPCBbGtVWvaQhaDbT7YjNREf0e9tGPw8YdXQ4REaYqjdWyKJ8MOKHAECqOCAQ0w
ggEJMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUSdswL0JvwVGY2XPU
JSdi4ALig9EwgaIGA1UdHwSBmjCBlzCBlKBZoFeGVWh0dHA6Ly8xNzIuMTcuMjEu
NjUvZWpiY2EvcHVibGljd2ViL2NybHMvc2VhcmNoLmNnaT9pSGFzaD15SDYwdlFC
aEZGbFhCVFE5VDNadjIwMkUwVUWiN6Q1MDMxFjAUBgNVBAMMDU15UEtJU3ViQ0Et
RzExDDAKBgNVBAoMA01USTELMAkGA1UEBhMCREswHQYDVR0OBBYEFPpTVzolNqYK
R/2CMv18kQAPVkHnMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDBANIADBFAiEA
wtZtv5MhTXKwz3sjA4KAracuUWsSgSZ+wOckZOANVKICIBIrHQgkiPcOEpL3RHoH
P5S25wQNlP92rSwehF+IQtNh
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICWzCCAgKgAwIBAgIUJDSYUfPk8hjZ18YOFaWzPwBd7ZgwCgYIKoZIzj0EAwQw
NzELMAkGA1UEBhMCREsxDDAKBgNVBAoMA01USTEaMBgGA1UEAwwRTXkgUEtJIFJv
b3QgQ0EtRzEwIBcNMjQxMDE2MDkxMTUzWhgPMjA1NDEwMDkwOTExNTJaMDcxCzAJ
BgNVBAYTAkRLMQwwCgYDVQQKDANNVEkxGjAYBgNVBAMMEU15IFBLSSBSb290IENB
LUcxMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAENk8xOK4LiV0W6ySbymrOgRTc
5VvLdgU12TKM4lTRrE9CTgi8R25u0sGMBGGE6zLE7nZYN4Wv9MHvfPo3SKc0JqOB
6TCB5jAPBgNVHRMBAf8EBTADAQH/MIGjBgNVHR8EgZswgZgwgZWgWaBXhlVodHRw
Oi8vMTcyLjE3LjIxLjY1L2VqYmNhL3B1YmxpY3dlYi9jcmxzL3NlYXJjaC5jZ2k/
aUhhc2g9cG1UbFdvRndMVFkvT0cxQjNVNTBLSW5lcXpzojikNjA0MRcwFQYDVQQD
DA5NeVBLSVJvb3RDQS1HMTEMMAoGA1UECgwDTVRJMQswCQYDVQQGEwJESzAdBgNV
HQ4EFgQUSdswL0JvwVGY2XPUJSdi4ALig9EwDgYDVR0PAQH/BAQDAgGGMAoGCCqG
SM49BAMEA0cAMEQCIDGQTWJvK9FtM3iK8HVyMs0M9PuXhQWQRZ+OX5DmgrksAiAR
8abUuAhLieixPZRdSKsUhkbINVUXWPobiDYdZYK/Bw==
-----END CERTIFICATE-----
root@dot1x-Thinkpad:/usr/local/share/ca-certificates#

Since the machine is not joined to the domain, I don't understand what username do I need to define. While creating the certificate, it ask for the username.
I have a ticket open with Microsoft, and they say, NPS configuration on server 2022 looks OK.

Please suggest.

Kind regards,
Khalid

[primetomas]

I start with client certificate. Client certificate is issued by the SubCA. But CDP seem to point to Root CA:
X509v3 CRL Distribution Points:
Full Name:
URI:http://172.17.21.65/ejbca/publicweb/crls/search.cgi?iHash=pmTlWoFwLTY/OG1B3U50KIneqzs CRL Issuer:
DirName:CN = My PKI Root CA-G1, O = MTI, C = DK

The client certificate is issued by the SubCA, and it's CDP should therefore point to the CRL issued by the SubCA.

Also "keyEncipherment" is not an allowed keyUsage for EC keys. Remove that.

The CDP does not conform to RFC5280 with usage of both URI and CRLIssuer:
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.13
"If the certificate issuer is also the CRL issuer, then conforming CAs MUST omit the cRLIssuer field and MUST include the distributionPoint field."

As I assume that the certificate issuer and the CRL issuer are the same here, as this is the only option EJBCA supports (and the only option used in all relevant PKIs you can find).

[eamkhal]

Hi Tomas,

Thank you for the support. The issue has now been fixed. I made changes as you suggested. Also we replaced windows based NPS to Linux based Free radius and they client got authenticated in first attempt.
Once again, I would like to thank for your time and support.
Kind regards, Khalid