LDAPS Port 636 and cert installation

dev support
1

Hello all. I have a question regarding LDAPS (port 636) and installing certificates. I have been working with my network admin to get certs installed so we can use LDAPS. We have been struggling. One major area of difficulty is the documentation and how it matches up with our folder structure. We have been following this:

According to the docs, the first path on the docs shows: {path_to_lucee}\jdk\lib\security
My folder structure is similar: {path_to_lucee}\jdk\jre\lib\security\

So I think we have PATH1 figured out (needed the JRE). We installed the cacerts here.

The 2nd path on the docs shows: {path_to_webserver}\WEB-INF\lucee\security
I donā€™t have a closely matching path but we tried: tomcat\lucee-server\context\security

Iā€™m not sure if that is where it is supposed to go but my 2nd path has a cacerts file so it made sense. We installed the ca certs in this 2nd path.

The 3rd path on the docs shows: c:{path_to_tomcat_root}\webapps\ROOT\WEB-INF\lucee\security
I have a matching path in my folder structure but this doesnā€™t have any cacerts file to replace.

Questions:

  1. Is my path okay for PATH1 (adding the JRE)?
  2. Is the path for PATH2 ok? If not, where should we be looking?
  3. What should I do about PATH3? Put in a dummy cacerts file and then import?
  4. The docs say to install the CACERTS file as well as an INTERMEDIATE file. My admin says the INTERMEDIATE file is ā€œrolled upā€ in the CACERTS file. Do we need both?
  5. Is there any other documentation out there for this? This is not a strong suit for either of us so any direction can help.
    Thanks!!

OS: Windows Server 2016
Java, Tomcat and Lucee were installed at 5.2.5.020,
Java Version: 1.8.0_152
Tomcat Version: 8.5.24
Lucee Version: 5.3.5.92
** Apache 2.4

2

Hi Brasche, never did that and I had to manually install certificates just once for some cfhttp calls using tomcats/javas jdk keystores manually some time ago. But isnā€™t there a import certificates section in lucees server admin or web admin gui now for that kind of ssl stuff? Did you take a look into that approach? As I"ve said, I donā€™t have much experience with that, but this might be an idea/hint until some more experienced guys/gals chime in to help.

3

Thanks for the reply andreas. I use Apache 2.4 and have the certs installed there for web SSL. I have also used the admin for the certs but I didnā€™t think that is for LDAPS. I will see what I can find out about it though. It would be great if it were that easy.

4

I went in and did that, using our main DC as the host and port 636. It appears to be working. Iā€™ll do some more testing tomorrow but it looks very promising. Thank you!

5

Perfect. Wish you good luck. The SSL section in lucees server admin/web admin is, as far i am informed, for exactly the purpose of importing certifcates to JVMs keystores (for example cfhttp requests) and not installing certificates for fronting webservers (apache/iis).

For cfldap and ssl there is a post in our foeum, a little bit old, but still might be of good value to read.
https://lucee.daemonite.io/t/cfldap-and-ssl/1582

Wish you the best luck tomorrow when digging into this at your work.

6

Just a quick update in case someone else needs to do this in the futureā€¦
I needed to install the CA cert in 2 spots:

  1. using the keytool @ {path_to_lucee}\jdk\jre\lib\security\ The admin tool in #2 did not touch this path.
  2. the Admin SSL certs section. This automatically put the cert in tomcat\lucee-server\context\security. NOTE: I had to enter in each domain controller I am connecting to. Donā€™t forget to put in the correct port.

I needed certs in both folders before I could get it to work.

After the restart, it seems to be working.

There might be a more proper or elegant way to do this but itā€™s working.

Thanks for your help!

1 Like
7

Great News @brasche !!! Glad you got it working. And welcome to our community and thanks for posting your solution here. That will help orhers for sure.

8

Here is another input.

The SSL section in the administrative console seems to be for this exact task however it can also be done manually.

If you donā€™t have the LDAP certificate then use OpenSSL to obtain it using the command like

openssl s_client -connect ldap.servername.com:636

Then save the certificate in a file (e.g. ā€œC:\downloads\ldap.servername.com.cerā€)

There are two keystores with Lucee and I think you only need to place the certificate in the first one but I place it in both, just in case.

From the C:\lucee\jre\bin folder issue the following command from an administrator command prompt, changing the certificate names as applicable.

keytool -keystore "C:\lucee\tomcat\lucee-server\context\security\cacerts" -importcert -alias LDAP.SERVERNAME.COM -file "C:\downloads\ldap.servername.com.cer" -storepass changeit

You will be asked to confirm that you trust the certificate. Do it again as below, just in case.

keytool -keystore "C:\lucee\jre\lib\security\cacerts" -importcert -alias LDAP.SERVERNAME.COM -file "C:\downloads\ldap.servername.com.cer" -storepass changeit

1 Like
9

Sorry for bringing back an old post but struggling here to get secure LDAP to work in Lucee.

Iā€™ve added the certificates for two servers from the Admin SSL Certificates section but that doesnā€™t give me a secure LDAP connection on port 636 to either server using either of the two secure options. Works fine using port 389 without the secure option.

I can see from this that as well as the Admin area, it looks like you need to manually install certificates elsewhere?

Iā€™ve used OpenSSL to view the certificates in a Windows command prompt but how do I go about getting them into Lucee?

OpenSSL is new to me so was struggling there at first, many examples give ā€˜sedā€™ as an option but that was erroring and I also saw from some tests I need x509.

From a Windows command prompt with access to OpenSSL, what command string do I need to get each certificate in turn?

What do I do then with those certificates? I assume they need to be incorporated into the existing cacert file?

The existing documentation at Setting Up Secure LDAP :: Lucee Documentation is sadly lacking.

Any/all help and guidance really appreciated.

10

Hi,

Not sure about Windows, but weā€™re running Lucee in Docker and to get the certs installed so that we can LDAPS we need to install the certificates via the keytool on build.

We do it like

# Variables
keystore=$LUCEE_HOME/server/lucee-server/context/security/cacerts
keypass=changeit
file=**FULL PATH TO CERT**

echo -n "importing $(basename $file)... "
keytool -import -keystore $keystore -alias "$(basename $file)" -storepass $keypass -noprompt -trustcacerts -file "$file"

Once the certs are installed that way, we could access LDAPS. Using the admin or the SSLCertificateInstall didnā€™t seem to work for us.

HTH

1 Like
11

Lucee 6.0 will default to using your JVMā€™s own cacerts file (the admin has been updated to explain this)

the old behaviour (using the lucee supplied cacaerts) can be enabled via lucee.use.lucee.SSL.TrustStore=true

This was done as JVMs get updated much more regularly than Lucee

https://luceeserver.atlassian.net/browse/LDEV-917

1 Like
12

Thanks both. Using Lucee 5.3.8.201 here so still the old way for now.

So still looking at obtaining the certificate and using the keytool to add it to the existing cacert file then I guess?

Iā€™m still struggling with obtaining the certificate from the server though using openSSL
from a windows cmd prompt, where {serverURL} is the server, what command string I need to end up with a valid file from it in order to use the keytool commands as posted by jedihomer above.

13

This :smiley:

The commandline for windows should be the same. Iā€™d fill this out a bit more, based on site compatibility.

First -showcerts gives you all the certificates instead of just the leaf certificate.
Second, -servername enables the TLS SNI Extension - which youā€™d need for certain sites.

So, i.e. letā€™s grab google.

openssl s_client -connect www.google.com:443 -showcerts -servername www.google.com

Then hit ctrl-c - because you donā€™t actually want to talk to google. (or hit enter until it exits)

(Note port 443 is for HTTPS and port 636 is for LDAPS)

$ openssl s_client -connect www.google.com:443 -showcerts -servername www.google.com
CONNECTED(00000005)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = www.google.com
verify return:1
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIRAK//jqI8CPcfCgAAAAEuB3owDQYJKoZIhvcNAQELBQAw
RjELMAkGA1UEBhMCVVMxIjAgBgNVBAoTGUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBM
TEMxEzARBgNVBAMTCkdUUyBDQSAxQzMwHhcNMjIwMTEwMDMzNTMyWhcNMjIwNDA0
MDMzNTMxWjAZMRcwFQYDVQQDEw53d3cuZ29vZ2xlLmNvbTBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABNXELhu6Vprhg/AEhN/zi16JPcov/FLl7ldjSzhXOcsv01yl
dzHvXSSDJ75B7M4T8Bw7g907uuWJ4RQafcuK4n6jggJpMIICZTAOBgNVHQ8BAf8E
BAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUzPrcxRuC0t6LvXF4AVtuDLAVSmIwHwYDVR0jBBgwFoAUinR/r4XN7pXNPZzQ
4kYU83E1HScwagYIKwYBBQUHAQEEXjBcMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz
cC5wa2kuZ29vZy9ndHMxYzMwMQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kuZ29vZy9y
ZXBvL2NlcnRzL2d0czFjMy5kZXIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20w
IQYDVR0gBBowGDAIBgZngQwBAgEwDAYKKwYBBAHWeQIFAzA8BgNVHR8ENTAzMDGg
L6AthitodHRwOi8vY3Jscy5wa2kuZ29vZy9ndHMxYzMvZlZKeGJWLUt0bWsuY3Js
MIIBBgYKKwYBBAHWeQIEAgSB9wSB9ADyAHcARqVV63X6kSAwtaKJafTzfREsQXS+
/Um4havy/HD+bUcAAAF+QkUdvQAABAMASDBGAiEA1TKRPyZR4zyG6pwtX1Tfu9oV
Kq9CrttoiZtWYLkh4fkCIQD/Pu5JHjut+7AN9cnPCDa5oGMe5WfPM2cehLWZhha5
bQB3AEHIyrHfIkZKEMahOglCh15OMYsbA+vrS8do8JBilgb2AAABfkJFHbcAAAQD
AEgwRgIhAJcOYFi8YgTYmjNRHJDKLP8rvlk6MGPTSEJ3SF0CRZoEAiEAqt8Rj5Pa
ndUuFURwNdzs7pdI3NvkzPLc3t11vhmZGKQwDQYJKoZIhvcNAQELBQADggEBADsy
RJII9KlEqgHvqbJvYAsPlRF2lNjjbPRt5iviUhEkYPuv6q36ShtENHg164BQoPOt
l8oDHXI/iGAmfJNrqbWJW7UHmHvWpQfAa7SOuETgZfXYXrrxNUd9oHI1+6GEtBvv
sBu5CwtigrGmiaf/DDY8zxlFRVx4vYWPNFSa/OswmxTUwppxzj/AhzB4KH+7LfJV
0Hll4ZUlBuLpy/r8cbbPX9KgQnCxY3xHgvTyNJyxNjY0ahf/C4WkADvmEbHRZTfh
JLIJBFdx0gTKExZFYWE37oKy3AwC4jSko45F+muglxbbD5VM9E2c+3fNBLOZdPWn
iQB8WQEO+ZEpFBT9WDY=
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
MIIFljCCA36gAwIBAgINAgO8U1lrNMcY9QFQZjANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExMQzEU
MBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMjAwODEzMDAwMDQyWhcNMjcwOTMwMDAw
MDQyWjBGMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZp
Y2VzIExMQzETMBEGA1UEAxMKR1RTIENBIDFDMzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAPWI3+dijB43+DdCkH9sh9D7ZYIl/ejLa6T/belaI+KZ9hzp
kgOZE3wJCor6QtZeViSqejOEH9Hpabu5dOxXTGZok3c3VVP+ORBNtzS7XyV3NzsX
lOo85Z3VvMO0Q+sup0fvsEQRY9i0QYXdQTBIkxu/t/bgRQIh4JZCF8/ZK2VWNAcm
BA2o/X3KLu/qSHw3TT8An4Pf73WELnlXXPxXbhqW//yMmqaZviXZf5YsBvcRKgKA
gOtjGDxQSYflispfGStZloEAoPtR28p3CwvJlk/vcEnHXG0g/Zm0tOLKLnf9LdwL
tmsTDIwZKxeWmLnwi/agJ7u2441Rj72ux5uxiZ0CAwEAAaOCAYAwggF8MA4GA1Ud
DwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEgYDVR0T
AQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUinR/r4XN7pXNPZzQ4kYU83E1HScwHwYD
VR0jBBgwFoAU5K8rJnEaK0gnhS9SZizv8IkTcT4waAYIKwYBBQUHAQEEXDBaMCYG
CCsGAQUFBzABhhpodHRwOi8vb2NzcC5wa2kuZ29vZy9ndHNyMTAwBggrBgEFBQcw
AoYkaHR0cDovL3BraS5nb29nL3JlcG8vY2VydHMvZ3RzcjEuZGVyMDQGA1UdHwQt
MCswKaAnoCWGI2h0dHA6Ly9jcmwucGtpLmdvb2cvZ3RzcjEvZ3RzcjEuY3JsMFcG
A1UdIARQME4wOAYKKwYBBAHWeQIFAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3Br
aS5nb29nL3JlcG9zaXRvcnkvMAgGBmeBDAECATAIBgZngQwBAgIwDQYJKoZIhvcN
AQELBQADggIBAIl9rCBcDDy+mqhXlRu0rvqrpXJxtDaV/d9AEQNMwkYUuxQkq/BQ
cSLbrcRuf8/xam/IgxvYzolfh2yHuKkMo5uhYpSTld9brmYZCwKWnvy15xBpPnrL
RklfRuFBsdeYTWU0AIAaP0+fbH9JAIFTQaSSIYKCGvGjRFsqUBITTcFTNvNCCK9U
+o53UxtkOCcXCb1YyRt8OS1b887U7ZfbFAO/CVMkH8IMBHmYJvJh8VNS/UKMG2Yr
PxWhu//2m+OBmgEGcYk1KCTd4b3rGS3hSMs9WYNRtHTGnXzGsYZbr8w0xNPM1IER
lQCh9BIiAfq0g3GvjLeMcySsN1PCAJA/Ef5c7TaUEDu9Ka7ixzpiO2xj2YC/WXGs
Yye5TBeg2vZzFb8q3o/zpWwygTMD0IZRcZk0upONXbVRWPeyk+gB9lm+cZv9TSjO
z23HFtz30dZGm6fKa+l3D/2gthsjgx0QGtkJAITgRNOidSOzNIb2ILCkXhAd4FJG
AJ2xDx8hcFH1mt0G/FX0Kw4zd8NLQsLxdxP8c4CU6x+7Nz/OAipmsHMdMqUybDKw
juDEI/9bfU1lcKwrmz3O2+BtjjKAvpafkmO8l7tdufThcV4q5O8DIrGKZTqPwJNl
1IXNDw9bg1kWRxYtnCQ6yICmJhSFm/Y3m6xv+cXDBlHz4n/FsRC6UfTd
-----END CERTIFICATE-----
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIFYjCCBEqgAwIBAgIQd70NbNs2+RrqIQ/E8FjTDTANBgkqhkiG9w0BAQsFADBX
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UE
CxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTIwMDYx
OTAwMDA0MloXDTI4MDEyODAwMDA0MlowRzELMAkGA1UEBhMCVVMxIjAgBgNVBAoT
GUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBMTEMxFDASBgNVBAMTC0dUUyBSb290IFIx
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAthECix7joXebO9y/lD63
ladAPKH9gvl9MgaCcfb2jH/76Nu8ai6Xl6OMS/kr9rH5zoQdsfnFl97vufKj6bwS
iV6nqlKr+CMny6SxnGPb15l+8Ape62im9MZaRw1NEDPjTrETo8gYbEvs/AmQ351k
KSUjB6G00j0uYODP0gmHu81I8E3CwnqIiru6z1kZ1q+PsAewnjHxgsHA3y6mbWwZ
DrXYfiYaRQM9sHmklCitD38m5agI/pboPGiUU+6DOogrFZYJsuB6jC511pzrp1Zk
j5ZPaK49l8KEj8C8QMALXL32h7M1bKwYUH+E4EzNktMg6TO8UpmvMrUpsyUqtEj5
cuHKZPfmghCN6J3Cioj6OGaK/GP5Afl4/Xtcd/p2h/rs37EOeZVXtL0m79YB0esW
CruOC7XFxYpVq9Os6pFLKcwZpDIlTirxZUTQAs6qzkm06p98g7BAe+dDq6dso499
iYH6TKX/1Y7DzkvgtdizjkXPdsDtQCv9Uw+wp9U7DbGKogPeMa3Md+pvez7W35Ei
Eua++tgy/BBjFFFy3l3WFpO9KWgz7zpm7AeKJt8T11dleCfeXkkUAKIAf5qoIbap
sZWwpbkNFhHax2xIPEDgfg1azVY80ZcFuctL7TlLnMQ/0lUTbiSw1nH69MG6zO0b
9f6BQdgAmD06yK56mDcYBZUCAwEAAaOCATgwggE0MA4GA1UdDwEB/wQEAwIBhjAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTkrysmcRorSCeFL1JmLO/wiRNxPjAf
BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzBgBggrBgEFBQcBAQRUMFIw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjEwKQYIKwYBBQUH
MAKGHWh0dHA6Ly9wa2kuZ29vZy9nc3IxL2dzcjEuY3J0MDIGA1UdHwQrMCkwJ6Al
oCOGIWh0dHA6Ly9jcmwucGtpLmdvb2cvZ3NyMS9nc3IxLmNybDA7BgNVHSAENDAy
MAgGBmeBDAECATAIBgZngQwBAgIwDQYLKwYBBAHWeQIFAwIwDQYLKwYBBAHWeQIF
AwMwDQYJKoZIhvcNAQELBQADggEBADSkHrEoo9C0dhemMXoh6dFSPsjbdBZBiLg9
NR3t5P+T4Vxfq7vqfM/b5A3Ri1fyJm9bvhdGaJQ3b2t6yMAYN/olUazsaL+yyEn9
WprKASOshIArAoyZl+tJaox118fessmXn1hIVw41oeQa1v1vg4Fv74zPl6/AhSrw
9U5pCZEt4Wi4wStz6dTZ/CLANx8LZh1J7QJVj2fhMtfTJr9w4z30Z209fOU0iOMy
+qduBmpvvYuR7hZL6Dupszfnw0Skfths18dG9ZKb59UhvmaSGZRVbNQpsg3BZlvi
d0lIKO2d1xozclOzgjXPYovJJIultzkMu34qQb9Sz/yilrbCgj8=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = www.google.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4296 bytes and written 396 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
^C

Youā€™ll see google is actually sending us a chain with 3 certificates

Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA

(snipped out the base64 certs themselves)

Cert 0 is the leaf certificate - the one on the server. Cert 1 and 2 are intermediate certificates (they have other issuers), and the globalsign Root CA is the actual, trusted internet root.

If google WERENā€™T trusted, Iā€™d add cert 2 to the cacerts, which means anything signed by ā€œGTS Root R1ā€ would be implicitly trusted. This is why you donā€™t have to manually add certs from sites on the internet, and also why using the system store/jvm store is preferable in most cases, because routine updates do happen.

At work, I have my own CA for internal resources, so my chain looks like this:

CONNECTED(00000005)
depth=1 DC = net, DC = k12system, DC = win, CN = K12 Systems Hosting CA
verify return:1
depth=0 C = US, ST = Pennsylvania, L = Allentown, O = K12 Systems Inc, OU = Information Technology, CN = InstanceManagement.tkp.k12system.net
verify return:1
---
Certificate chain
 0 s:C = US, ST = Pennsylvania, L = Allentown, O = K12 Systems Inc, OU = Information Technology, CN = InstanceManagement.tkp.k12system.net
   i:DC = net, DC = k12system, DC = win, CN = K12 Systems Hosting CA
 1 s:DC = net, DC = k12system, DC = win, CN = K12 Systems Hosting CA
   i:DC = net, DC = k12system, DC = win, CN = K12 Systems Hosting CA

0 is the leaf - itā€™s the site
1 is my CA. Notice the issuer and the subject are the same - itā€™s self signed. If you were to hit this site (which you canā€™t cuz itā€™s not internet accessible), youā€™d get a warning.

So I can either add cert 1 to my cacerts (which then trusts ANY cert my organization signs) or I can add the leaf cert (0) to my cacerts, and then I have to do every site I want to connect to.

I put my cacerts in the containers. I do it at the os level (so, in docker, I follow whatever the linux base os does for certificates, usually a folder in /usr/share/ca-certificates that is linked back to /etc/ssl/certs/ and hashed with something like update-ca-certificates, and then I link the /etc/ssl/certs/java/cacerts file back into lucee so it uses the system trust.)

Long story short (too late)

The cert is the base64 with header+footer, so if you were passing the cert to keytool, and you wanted googleā€™s leaf cert 0 from the above example, youā€™d make a text file that includes this:

0 s:CN = www.google.com
  i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIRAK//jqI8CPcfCgAAAAEuB3owDQYJKoZIhvcNAQELBQAw
RjELMAkGA1UEBhMCVVMxIjAgBgNVBAoTGUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBM
TEMxEzARBgNVBAMTCkdUUyBDQSAxQzMwHhcNMjIwMTEwMDMzNTMyWhcNMjIwNDA0
MDMzNTMxWjAZMRcwFQYDVQQDEw53d3cuZ29vZ2xlLmNvbTBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABNXELhu6Vprhg/AEhN/zi16JPcov/FLl7ldjSzhXOcsv01yl
dzHvXSSDJ75B7M4T8Bw7g907uuWJ4RQafcuK4n6jggJpMIICZTAOBgNVHQ8BAf8E
BAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUzPrcxRuC0t6LvXF4AVtuDLAVSmIwHwYDVR0jBBgwFoAUinR/r4XN7pXNPZzQ
4kYU83E1HScwagYIKwYBBQUHAQEEXjBcMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz
cC5wa2kuZ29vZy9ndHMxYzMwMQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kuZ29vZy9y
ZXBvL2NlcnRzL2d0czFjMy5kZXIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20w
IQYDVR0gBBowGDAIBgZngQwBAgEwDAYKKwYBBAHWeQIFAzA8BgNVHR8ENTAzMDGg
L6AthitodHRwOi8vY3Jscy5wa2kuZ29vZy9ndHMxYzMvZlZKeGJWLUt0bWsuY3Js
MIIBBgYKKwYBBAHWeQIEAgSB9wSB9ADyAHcARqVV63X6kSAwtaKJafTzfREsQXS+
/Um4havy/HD+bUcAAAF+QkUdvQAABAMASDBGAiEA1TKRPyZR4zyG6pwtX1Tfu9oV
Kq9CrttoiZtWYLkh4fkCIQD/Pu5JHjut+7AN9cnPCDa5oGMe5WfPM2cehLWZhha5
bQB3AEHIyrHfIkZKEMahOglCh15OMYsbA+vrS8do8JBilgb2AAABfkJFHbcAAAQD
AEgwRgIhAJcOYFi8YgTYmjNRHJDKLP8rvlk6MGPTSEJ3SF0CRZoEAiEAqt8Rj5Pa
ndUuFURwNdzs7pdI3NvkzPLc3t11vhmZGKQwDQYJKoZIhvcNAQELBQADggEBADsy
RJII9KlEqgHvqbJvYAsPlRF2lNjjbPRt5iviUhEkYPuv6q36ShtENHg164BQoPOt
l8oDHXI/iGAmfJNrqbWJW7UHmHvWpQfAa7SOuETgZfXYXrrxNUd9oHI1+6GEtBvv
sBu5CwtigrGmiaf/DDY8zxlFRVx4vYWPNFSa/OswmxTUwppxzj/AhzB4KH+7LfJV
0Hll4ZUlBuLpy/r8cbbPX9KgQnCxY3xHgvTyNJyxNjY0ahf/C4WkADvmEbHRZTfh
JLIJBFdx0gTKExZFYWE37oKy3AwC4jSko45F+muglxbbD5VM9E2c+3fNBLOZdPWn
iQB8WQEO+ZEpFBT9WDY=
-----END CERTIFICATE-----

Note that parsers are smart enough to look for the ā€”BEGIN CERTIFICATE and ā€”END CERTIFICATE lines, so you CAN include the descriptive lines at the top like I did - it makes it easier to identify the certificate for yourself later.

You can always see what the cert is using openssl as well, so if you dump the above text into a text file named mycert.pem

openssl x509 -noout -text -in mycert.pem

Will give you a full dump - i.e.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            af:ff:8e:a2:3c:08:f7:1f:0a:00:00:00:01:2e:07:7a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
        Validity
            Not Before: Jan 10 03:35:32 2022 GMT
            Not After : Apr  4 03:35:31 2022 GMT
        Subject: CN = www.google.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:d5:c4:2e:1b:ba:56:9a:e1:83:f0:04:84:df:f3:
                    8b:5e:89:3d:ca:2f:fc:52:e5:ee:57:63:4b:38:57:
                    39:cb:2f:d3:5c:a5:77:31:ef:5d:24:83:27:be:41:
                    ec:ce:13:f0:1c:3b:83:dd:3b:ba:e5:89:e1:14:1a:
                    7d:cb:8a:e2:7e
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                CC:FA:DC:C5:1B:82:D2:DE:8B:BD:71:78:01:5B:6E:0C:B0:15:4A:62
            X509v3 Authority Key Identifier:
                keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27

            Authority Information Access:
                OCSP - URI:http://ocsp.pki.goog/gts1c3
                CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der

            X509v3 Subject Alternative Name:
                DNS:www.google.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.11129.2.5.3

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.pki.goog/gts1c3/fVJxbV-Ktmk.crl

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D:
                                11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47
                    Timestamp : Jan 10 04:35:32.925 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:D5:32:91:3F:26:51:E3:3C:86:EA:9C:
                                2D:5F:54:DF:BB:DA:15:2A:AF:42:AE:DB:68:89:9B:56:
                                60:B9:21:E1:F9:02:21:00:FF:3E:EE:49:1E:3B:AD:FB:
                                B0:0D:F5:C9:CF:08:36:B9:A0:63:1E:E5:67:CF:33:67:
                                1E:84:B5:99:86:16:B9:6D
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 41:C8:CA:B1:DF:22:46:4A:10:C6:A1:3A:09:42:87:5E:
                                4E:31:8B:1B:03:EB:EB:4B:C7:68:F0:90:62:96:06:F6
                    Timestamp : Jan 10 04:35:32.919 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:97:0E:60:58:BC:62:04:D8:9A:33:51:
                                1C:90:CA:2C:FF:2B:BE:59:3A:30:63:D3:48:42:77:48:
                                5D:02:45:9A:04:02:21:00:AA:DF:11:8F:93:DA:9D:D5:
                                2E:15:44:70:35:DC:EC:EE:97:48:DC:DB:E4:CC:F2:DC:
                                DE:DD:75:BE:19:99:18:A4
    Signature Algorithm: sha256WithRSAEncryption
         3b:32:44:92:08:f4:a9:44:aa:01:ef:a9:b2:6f:60:0b:0f:95:
         11:76:94:d8:e3:6c:f4:6d:e6:2b:e2:52:11:24:60:fb:af:ea:
         ad:fa:4a:1b:44:34:78:35:eb:80:50:a0:f3:ad:97:ca:03:1d:
         72:3f:88:60:26:7c:93:6b:a9:b5:89:5b:b5:07:98:7b:d6:a5:
         07:c0:6b:b4:8e:b8:44:e0:65:f5:d8:5e:ba:f1:35:47:7d:a0:
         72:35:fb:a1:84:b4:1b:ef:b0:1b:b9:0b:0b:62:82:b1:a6:89:
         a7:ff:0c:36:3c:cf:19:45:45:5c:78:bd:85:8f:34:54:9a:fc:
         eb:30:9b:14:d4:c2:9a:71:ce:3f:c0:87:30:78:28:7f:bb:2d:
         f2:55:d0:79:65:e1:95:25:06:e2:e9:cb:fa:fc:71:b6:cf:5f:
         d2:a0:42:70:b1:63:7c:47:82:f4:f2:34:9c:b1:36:36:34:6a:
         17:ff:0b:85:a4:00:3b:e6:11:b1:d1:65:37:e1:24:b2:09:04:
         57:71:d2:04:ca:13:16:45:61:61:37:ee:82:b2:dc:0c:02:e2:
         34:a4:a3:8e:45:fa:6b:a0:97:16:db:0f:95:4c:f4:4d:9c:fb:
         77:cd:04:b3:99:74:f5:a7:89:00:7c:59:01:0e:f9:91:29:14:
         14:fd:58:36
2 Likes
14

Followed as explained, added to the cacert at "c:\lucee\jre\lib\security" and this time got the prompt to accept the certificate. Restarted Lucee, changed the LDAP query to port 636 and secure = ā€œCFSSL_BASICā€ and it logs in like a charm!

Did some checks to make sure was working as expected, e.g. tested with incorrect password, changed back to port 389 etc. Yep, confirmed!

Huge thanks Joe for taking the time to run that through for me. Top man!