Troubleshooting HTTPS Certificate Issues in SAS Viya: SSL Process Overview
As we all should be aware of, secure communication is essential, especially for platforms like SAS Viya, where analytics, AI, and data management are central to business operations. HTTPS certificates ensure data encryption and server identity verification, but even small misconfigurations can lead to significant issues, such as downtime, security risks, and compliance challenges. This blog series, "Troubleshooting HTTPS Certificate Issues in SAS Viya" will explore common SSL-related problems you may encounter in a SAS Viya environment. From expired certificates and mismatched domain names to navigating Kubernetes configurations and certificate chains, we'll provide clear insights and practical solutions for diagnosing and resolving these issues. Whether you're handling expired certificates, root CA issues, or Kubernetes-specific complexities, this series is designed to help you troubleshoot and resolve HTTPS certificate problems with confidence.
The first two blog posts in this series will lay the foundation by explaining the essential concepts and objects behind SSL implementation. Each subsequent post will dive into a specific, common SSL issue, providing detailed troubleshooting steps and solutions.
SSL Process Overview
The SSL process in a Kubernetes cluster with an Ingress controller and backend pods involves multiple layers of communication and encryption. Let me explain the key steps first, then I will describe the various SSL objects (mainly certificates and certificate authorities) needed to be stored.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
1. Client Request (SSL/TLS Initiation)
A user/client makes an HTTPS request to a web service or an application endpoint hosted in a Kubernetes cluster. The request is sent to the external IP of the Ingress controller, which is responsible for handling external traffic.
2. Ingress Controller SSL Termination
The Ingress controller is configured with an SSL certificate (either generated or provided manually or provided via services like Let's Encrypt). The Ingress controller receives the encrypted HTTPS request, decrypts it (SSL termination), and then forwards the request. Based on the Ingress rules, the controller forwards the request to the appropriate Kubernetes service object, which routes traffic to backend pods inside the Kubernetes cluster, using HTTP or HTTPS depending on the configuration.
3. SSL Passthrough or Re-encryption
SAS Viya does not support an SSL passthrough mode. This means encrypted traffic from the client is terminated at an intermediate layer, such as a Kubernetes Ingress controller, and cannot be forwarded as-is to the backend services (such as SAS Viya microservices or applications). SAS Viya employs SSL re-encryption in a “Full-Stack TLS” setup. Traffic from the client is decrypted at an intermediate point and then re-encrypted when forwarded to backend services, maintaining secure communication across the entire stack. By default, SAS Viya is deployed with Full-Stack TLS (Transport Layer Security) enabled, ensuring encrypted communication across all components within the platform. When encryption between the client and the backend is only established at the front door (the external interface like an Ingress) and there is no encryption to the backend, this configuration is called “Front-Door TLS”. In this setup, TLS encryption occurs between the client and the front door, but traffic between the front door and backend services is unencrypted. This might be used when internal backend traffic is trusted or occurs in a secure, isolated network.
4. Service Forwarding
The Ingress controller forwards the request to the respective Kubernetes service, which is an abstraction that directs the traffic to one or more backend pods based on load balancing rules.
5. Backend Pods
The request is received by one of the backend pods (representing a specific application or a microservice within the cluster), which processes the request and sends the response back to the Kubernetes service object. The Kubernetes service then forwards the response back to the Ingress controller.
6. Ingress Controller to Client (SSL)
The Ingress controller encrypts the response using the same SSL certificate and forwards the encrypted response back to the client over HTTPS.
Conclusion
In this post, we explored the SSL process within a Kubernetes-based SAS Viya environment, from client requests through Ingress termination and re-encryption, to backend service handling. Understanding these key steps is essential for ensuring secure communication across the stack. Stay tuned for the next post, where we’ll dive deeper into the Kubernetes objects involved in SSL, including certificates, certificate authorities, and ConfigMaps, to help you better understand how SSL works under the hood in SAS Viya.
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.
