topic Re: Change in SAS Viya 3.5 from LDAP to LDAPS in Administration and Deployment

Change in SAS Viya 3.5 from LDAP to LDAPS

Maicfel — Fri, 27 Mar 2026 12:21:51 GMT

I am changing the authentication type at the request of the infrastructure team from LDAP to LDAPS.

I performed the following steps on the SAS Viya 3.5 machine:

1 - In the Linux hosts file /etc/hosts, I added the new IP and new Host.

2 - I inserted the new certificate into the file /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem.

3 - I made the changes in the AS Environment Manager portal for the new IP, Port, and protocol in the LDAP URL to ldaps://${sas.identities.providers.ldap.connection.host}:${sas.identities.providers.ldap.connection.port}.

4 - I restarted sas-viya-saslogon sas-viya-identities.

5 - Log I'm getting the following error: "SSLHandshakeException / PKIX path building failed"

/opt/sas/viya/config/var/log/identities/default/sas-identities_2026-03-26_16-59-33.log

Can anyone help?

Thank you

Re: Change in SAS Viya 3.5 from LDAP to LDAPS

gwootton — Mon, 30 Mar 2026 16:53:00 GMT

This failure suggests an issue related to your step #2. The identities service does not have a trust chain to the certificate being served by the LDAP server.
Be sure you add certificates to the trust store using the method in the documentation rather than manually updating trustedcerts.pem:
Manage Truststores (Linux Full Deployment):
https://go.documentation.sas.com/doc/en/calcdc/3.5/calencryptmotion/n1xdqv1sezyrahn17erzcunxwix9.htm#n1lpxsg7iwc2kon1c8g3vez9tbpy

Re: Change in SAS Viya 3.5 from LDAP to LDAPS

Maicfel — Sat, 11 Apr 2026 03:04:13 GMT

Thank you for the guidance, you were absolutely right. The issue was exactly in that step, and your pointer to the certificate trust store documentation was the key to solving it.

Here is what worked in my environment:

Root cause
The CA certificates were provided as .pem files. The sas-merge-certificates.sh script only processes files with the .crt extension, so the CAchain was silently ignored and never added to trustedcerts.jks.

Steps that resolved the issue

1. Rename the CA certificate files from .pem to .crt and copy them to the SAS cacerts directory:

cp root.pem /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/root.crt
cp intermedia.pem /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/intermedia.crt

2. Run the merge script:

/opt/sas/viya/home/SASSecurityCertificateFramework/bin/sas-merge-certificates.sh

3. Verify the CA entries were imported into the trust store:

keytool -list -keystore \
/opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.jks \
-storepass changeit | grep -i "your-ca-name"

4. The sas-logon service (UAA) runs its own JVM and does not use the SAS trust store by default. It was still pointing to the standard
Java cacerts. Adding the following JVM options via Consul resolved the PKIX error on the logon side as well:

-Djavax.net.ssl.trustStore=.../trustedcerts.jks
-Djavax.net.ssl.trustStoreType=jks
-Djavax.net.ssl.trustStorePassword=changeit

5. Restart both sas-identities and sas-logon services.

The main takeaway, if your CA certificates are in .pem format, they must be renamed to .crt before the merge script will pick them up. And sas-logon requires its own explicit truststore configuration, separate from sas-identities.

Thanks again for pointing me in the right direction!

Re: Change in SAS Viya 3.5 from LDAP to LDAPS

gwootton — Mon, 13 Apr 2026 13:00:16 GMT

I'm a bit confused by this response, though I'm pleased to hear your issue is resolved.

The steps in the documentation I linked instruct you to store the contents of the cert files in the SAS Configuration Server (consul) and run the rebulid-trust-stores.yml playbook. The sas-merge-certificates.sh script is run by that playbook, not directly, retrieves the certificates from consul so the extension of the file is not relevant.

The script also adds in any crt files stored in the directory /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts, which seems to be what you're referring to, but to use that method you'd need to store the cert files with a .crt extension and store them on every host in the Viya 3 deployment, and is not what is in the documentation for this process.

Finally...the sas-logon service does use the SAS trust store by default, you don't need to add the javax.net.ssl.trustStore* options.

Re: Change in SAS Viya 3.5 from LDAP to LDAPS

Maicfel — Mon, 13 Apr 2026 14:59:44 GMT

Our deployment is a single-host Viya 3.5 environment, so copying the .crt files directly to /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/ and running the merge script directly was viable and effectively equivalent in our case, since there was only one host to update.

The .pem .crt rename was relevant precisely because we placed the files directly in the cacerts directory (the secondary method you mentioned), not via Consul. The script only picked up files with .crt extension from that directory, which is why the rename mattered.

Regarding sas-logon / UAA: after running the merge script, sas-identities connected successfully, but sas-logon was still throwing the PKIX error. We verified this by checking the logs separately. It is possible that in our specific environment the UAA JVM was not picking up the SAS trust store automatically, perhaps due to a configuration drift or a customization made previously by the infrastructure team. Adding the explicit JVM truststore options resolved it. We acknowledge this may not be the standard behavior.

In short, the core resolution aligned with what you pointed out, the certificates were not making it into trustedcerts.jks. The path we took to fix it differed slightly from the documented procedure due to environment-specific constraints, and I should have been clearer about that distinction in my original post.

Thank you again for keeping the thread technically accurate, it will help anyone else who finds this discussion.