Troubleshooting HTTPS Certificate Issues in SAS Viya: Self-Signed certificates
- Article History
- RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
In our previous post, we examined the challenges posed by mismatched domain names in your SAS Viya environment. Now, we turn our attention to self-signed certificates, another common SSL-related issue that can impact secure communication. Self-signed certificates are often used in development or testing environments due to their simplicity and cost-effectiveness, but they can introduce security risks if not managed properly. In this post, we will explore the characteristics of self-signed certificates, the scenarios in which they are appropriate, and the potential pitfalls of using them in production environments. By understanding how to effectively implement and manage self-signed certificates, you can help ensure the security and integrity of your SAS Viya platform.
Note: The $viya environment variable is used on kubectl
commands that require the --namespace
flag. Make sure that the environment variable is created before you use these kubectl
commands.
Self-Signed Certificates
Self-signed certificates are not trusted by default since they are not signed by a trusted Certificate Authority (CA), which leads to browser warnings and can impact secure communications.
Symptoms
When using self-signed certificates in your SAS Viya environment, web browsers often display security warnings, indicating the certificate is not trusted because it isn’t signed by a recognized Certificate Authority (CA). Some systems may block these connections or mark them as unsafe, disrupting access to the platform and hindering secure communication. Here is an example of the Error displayed if you were using Chrome:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
A self-signed certificate is determined if the Certificate Common Name (CN) has the same attribute as the “Issued By” CN.
Technical Diagnostic & Confirmation
Run these commands from a linux server that does have access to your Kubernetes cluster. It must have the kubectl and the openssl command line tools installed.
INGRESS_HOST=$(kubectl -n $viya get $(kubectl -n $viya get configmap --output name | grep ingress-input) -o jsonpath='{.data.INGRESS_HOST}'); \
echo X | openssl s_client -connect ${INGRESS_HOST}:443 -servername $INGRESS_HOST 2>/dev/null | openssl verify
If the certificate is self-signed or expired, you will see output similar to the following:
stdin: C = US, ST = North Carolina, L = Cary, O = SAS, CN = fradae-p02205-rg.gelenable.sas.com
error 18 at 0 depth lookup:self signed certificate
OK
Resolution
The best solution for production environments is to obtain a certificate from a trusted CA, which eliminates warnings and ensures secure communication. For development or internal testing, if self-signed certificates are necessary, you can add them to the trusted certificate store on all client machines. This will allow the certificates to be recognized and trusted, but it's not recommended for production due to the security risks involved. If want to add the self-signed certificate to trust store, follow the instructions from untrusted certificates blog post.
Conclusion
While self-signed certificates can be useful in development or testing environments, they pose significant security risks if used in production. Untrusted by default, these certificates can lead to browser warnings, blocked connections, and a false sense of security if not properly managed. To ensure the integrity of your SAS Viya platform, it’s crucial to use certificates issued by a trusted Certificate Authority (CA) in production environments. For internal or non-production use, adding self-signed certificates to trusted stores can mitigate some risks, but caution should always be exercised. In the next post, we will delve into another common SSL issue: incomplete certificate chain. Understanding how to address missing intermediate certificates is key to maintaining a secure and trusted connection within your SAS Viya environment.
For a deeper understanding, I highly recommend the comprehensive 'Advanced Topics in Encryption on SAS Viya' training. This course provides a thorough exploration of encryption, covering everything from core concepts to advanced techniques. It also includes hands-on exercises and an associated lab environment, allowing you to apply what you've learned in real-world scenarios and further strengthen your knowledge of secure communication within SAS Viya.
Be sure to check out the complete series on Troubleshooting HTTPS Certificate Issues for your SAS Viya platform to guide you through various common challenges and their resolutions.
- SSL Process Overview
- Kubernetes objects involved in SSL
- Expired Certificates
- Untrusted Certificates
- Mismatched Domain Names
- Self-Signed Certificates
- Incomplete Certificate Chain
- Analyzing Logs
Find more articles from SAS Global Enablement and Learning here.