--- title: "Dynamic certificate generation and SSL interception" canonical: "https://docs.aryaka.com/space/KNOW/20381701/Dynamic%20certificate%20generation%20and%20SSL%20interception" format: markdown --- Aryaka performs SSL interception of traffic that matches user-defined rules for Aryaka's Security Service and for the optimizations applied to the SD-WAN Service. The traffic that requires SSL interception can be defined as web traffic to public applications such as social media websites or to privately hosted servers like a build server. You can configure secure HTTP traffic bound to these servers or applications to be intercepted by Aryaka to provide security inspection, compression, or deduplication. To achieve this SSL interception, Aryaka performs on-demand dynamic generation of server certificates. As traffic travels through Aryaka, a determination is made whether to intervene in the SSL handshake between the client and the server. During this process, the server certificate offered by the original server is studied and mimicked by Aryaka’s SSL proxy and served to the client. This document describes the details of how the mimicked certificate is generated by the SSL proxy. Aryaka Secrets Manager The foundation of the dynamic certificate generation functionality is the Aryaka Secrets Manager (ASM). ASM is a secure, redundant private key store that uses HashiCorp Vault . All cryptographic functions that require the private key are performed on ASM so the secrets are never exposed outside of the server. Each Aryaka customer is assigned a Customer Certificate Authority by default. ASM generates the private key for the customer and stores it securely. This private key is used to generate a certificate signing request (CSR). By default, the CSR is signed by an Aryaka intermediate certificate authority for ease of onboarding. If you prefer, the CSR can be signed by a customer-selected certificate authority. The following graphic depicts the two CSR signing options: Customers that decide to have their certificate authority signed by a CA of their choosing can do so by performing the following process in MyAryaka: Download a new CSR. Have it signed by the selected CA. Upload it to MyAryaka. Note that if you select a private CA, you must upload their trust chain with the certificate. Customers that decide to use the certificate authority assigned to them by default must download Aryaka’s trust chain and configure their clients to trust it. Whichever certificate authority you use, it is now used to issue certificate authorities for each of your sites. You can revoke or invalidate this customer certificate authority at any time. For details on how to configure the certificate authority in MyAryaka, see the Manage certificate authority help topic. Dynamic certificate generation at sites Each customer site—whether it is an on-premises site with an ANAP deployed, a site with a third-party router, a hosted cloud site, or a private access concentrator on an Aryaka POP—gets a site-specific certificate authority. The ANAP or POP’s software generates a private key for each site. This private key is never written to disc and is only retained in memory. A CSR is generated using this private key and then is sent to the ASM, which then signs the site’s certificate authority. The site reissues a new private key every 24 hours and uses the new key to create a new CSR that is then sent to ASM for signature. The site certificate authority workflow is depicted in the following graphic: Each flow encountered by the processing engines on the ANAP or the POP searches its configuration to determine if SSL interception is required and for what purpose. The requirement may be for security purposes, SD-WAN optimization, or both. The exchange between the client and server is monitored and the server certificate is mimicked as closely as possible by the SSL proxy. This new mimicked certificate is returned to the client on behalf of the server. The certificate hierarchy is depicted in the following graphics: To enable a site’s certificate authority to issue dynamic certificates in MyAryaka, see the Manage site dynamic certificates help topic. SSL interception for security and SD-WAN optimization The following configurations affect traffic being intercepted by the Aryaka SSL proxy: Next Generation Firewall rule table Optimization rules The Next Generation Firewall (NGFW) security engine is an access control table that allows you to determine if all subsequent processing engines are bypassed, to proceed with further inspection, or to drop the traffic (to configure NGFW rules in MyAryaka, see the Configure a Next Generation Firewall ruleset help topic). If you decide that certain traffic requires additional inspection, the HTTPS traffic is forwarded and gets SSL interception before it encounters the Secure Web Gateway (SWG) Engine. The following graphic shows the network traffic flow and the SSL interception between the NGFW and the SWG engines: Optimization rules are an ordered list of rules that determine the series of interventions that Aryaka performs on your traffic that uses the Aryaka L2 Core network. These interventions can include TCP optimization, SSL interception, compression, deduplication, SMB proxying, and so on. To view your optimization rules in MyAryaka, see the View optimization rules help topic. The following graphic shows optimization-eligible traffic flowing between three site types over Aryaka’s L2 Core network: If either the NGFW rules or optimization rules require a flow to be intercepted, its SSL handshake is observed to determine the nature of the certificate being exchanged. A CSR is then generated that mimics the original server certificate and then it is signed by the site certificate authority. During this process, the server’s certificate is checked for its validity and is also checked against the trust store of the site. An invalid or untrusted server certificate is not mimicked by Aryaka. If you require a custom trust store, you can configure one using MyAryaka . After the trusted, valid certificate is mimicked and presented to the client, the end-to-end flow is encrypted and decrypted by Aryaka as necessary. In all intermediate hops along the path, the traffic is decrypted using dynamically generated in-memory tokens so that the traffic never traverses the network unencrypted. In this topic Related topics Manage certificate authority Manage site dynamic certificates Configure a Next Generation Firewall ruleset