128technology · madamsJuniper · May 15, 2026 · May 15, 2026
@@ -8,6 +8,7 @@ sidebar_label: Certificate Requirements and Validation
 | Release | Modification                |
 | ------- | --------------------------- |
 | 7.0.0   | Certificate management and validation support added. |
+| 7.2.0   | Subject Alternative Name URI support for peering identity. |
 
 This page describes the certificate properties that the SSR enforces, how `validation-mode` affects behavior, and the differences between config-time and runtime validation.
 
@@ -112,6 +113,7 @@ Client certificates used for peering are validated as leaf (end-entity) certific
 | --- | --- |
 | Signature Algorithm | Must be an [accepted algorithm](#accepted-cryptographic-algorithms). |
 | Public Key | Must be an [accepted key type and size](#key-requirements). |
+| Subject Alternative Name (optional) | Starting in SSR 7.2.0, a `urn:ssr:peering:<alias>` SAN URI can be used to carry SVR peering identity as an alternative to the Common Name. See [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#api-naming-rules) for details. |
 
 ### Intermediate CA Certificates
 

@@ -7,7 +7,8 @@ sidebar_label: Configure Certificate Management
 
 | Release | Modification                |
 | ------- | --------------------------- |
-| 7.0.0   | Certificate Management support added. | 
+| 7.0.0   | Certificate Management support added. |
+| 7.2.0   | Subject Alternative Name support added to CSR generation. | 
 
 Security is a critical component of SD-WAN products. The effectiveness of any security strategy relies on the strength of the security algorithm and how related information is exchanged between participants.
 
@@ -51,8 +52,8 @@ The following are some details of certificate security.
 
 ## Provisioning Process
 
-:::important
-It is necessary for all of the REST APIs to use the name `custom_ssr_peering` in order for this private key and certificate to be visible and usable by Enhanced Security Key Management in 7.0. This is a reserved name specifically used by the Enhanced Security Key Management feature.
+:::note Legacy Name
+In SSR 7.0.x, the `name` field in all REST API calls was required to be `custom_ssr_peering` (a reserved name) for ESKM visibility. Starting with SSR 7.1.0, any consistent name may be used. The examples below use `my_peering_cert`.
 :::
 
 :::tip Swagger API Reference
@@ -191,7 +192,7 @@ Create the following file (update algorithm and key size to your preference):
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "algorithm": "RSA",
     "rsa_key_size": "2048"
 }
@@ -213,7 +214,7 @@ curl -k -X POST https://10.27.35.89/api/v1/router/combo-east/node/node2/private-
   -d @key_request.json
 ```
 
-Upon success, `ssh` to the target SSR and verify that `/etc/128technology/pki/custom_ssr_peering.key` exists on disk.
+Upon success, `ssh` to the target SSR and verify that `/etc/128technology/pki/my_peering_cert.key` exists on disk.
 
 ### Issue a `certificate-signing-request`
 
@@ -226,11 +227,13 @@ This requirement is lifted starting with SSR 7.1.0.
 :::
 <!---remove this note when 7.0.4 is released and the restriction is lifted for 7.0.x --->
 
-1. Create a file containing the CSR request body. At a minimum provide `name` and a `common_name` that is unique to this router or node:
+1. Create a file containing the CSR request body. At a minimum provide `name` and a `common_name`:
 
 :::important Naming Rules
-- **`name`** must be **the same value across all routers and nodes** — `custom_ssr_peering` in SSR 7.0.x (reserved). This is the authority-wide identifier required for ESKM visibility.
-- **`common_name`** must be **unique per router/node** and must **exactly match** that router's configured `peering-common-name`. Using the wrong `common_name` will cause ESKM peer authentication to fail.
+- **`name`** must be **the same value across all routers and nodes**. In SSR 7.1+, any consistent name may be used.
+- **`common_name`** must be **unique per router/node**. It must match that router's configured `peering-common-name` — either directly, or via a `urn:ssr:peering` SAN URI in the certificate (SSR 7.2.0+).
+
+For full details on SAN URI peering identity, see [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#api-naming-rules).
 
 Example mapping for a two-router deployment:
 
@@ -240,15 +243,27 @@ Example mapping for a two-router deployment:
 | combo-west | `west-alias` | `west-alias` |
 :::
 
-**csr_request.json**
+**csr_request.json** (minimum):
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "common_name": "east-alias"
 }
 ```
 
+**csr_request.json** (with Subject Alternative Name URI for HA):
+
+```json
+{
+    "name": "my_peering_cert",
+    "common_name": "combo-east-node1",
+    "subject_alt_names": [
+        {"type": "urn_ssr_peering", "value": "east-alias"}
+    ]
+}
+```
+
 This example represents the minimum requirements. Any of the following additional details may be added to the request:
 
 - country_name (string, optional): The country name.
@@ -261,6 +276,12 @@ This example represents the minimum requirements. Any of the following additiona
 - rsa_key_size (integer, optional): The RSA key size. Only valid when algorithm is set to “RSA”. Valid key sizes are any multiple of 256 between 2048 and 4096.
 - ecc_curve (string, optional): The ECC curve to use. Only valid when algorithm is set to “ECC”.Valid curves are: (SECP256R, SECP384R1, SECP521R1)
 - validity_period (integer, optional): The validity period in days.
+- subject_alt_names (array, optional, SSR 7.2.0+): An array of Subject Alternative Name entries to include in the CSR. Each entry is an object with `type` and `value` fields. Supported types:
+  - `dns` — a DNS hostname (e.g., `"example.com"`)
+  - `ip` — an IPv4 or IPv6 address (e.g., `"192.168.1.1"`)
+  - `email` — an email address (e.g., `"admin@example.com"`)
+  - `uri` — a URI (e.g., `"https://example.com"`)
+  - `urn_ssr_peering` — a convenience alias that automatically expands the value to `URI:urn:ssr:peering:<value>`. Use this type to carry the SVRv2 peering identity in the SAN extension.
 
 2. Issue the CSR request to the SSR:
 
@@ -301,7 +322,7 @@ When the signed certificate is returned, instruct the SSR to ingest the certific
 ```
 POST /api/v1/router/{router_name}/node/{node_name}/certificate
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "certificate": "-----BEGIN CERTIFICATE-----
 MIIF3DCCBESgAwIBAgIKAf9HQjJKSQd1lTANBgkqhkiG9w0BAQsFADBaMQswCQYD
 VQQGEwJERTERMA8GA1UECgwIT3BlblhQS0kxDDAKBgNVBAsMA1BLSTEqMCgGA1UE
@@ -319,8 +340,8 @@ Once the certificate is successfully ingested, verify that the certificate was a
 
 1. `ssh` to the SSR. 
 2. Log in as the root user: `sudo su`.
-3. Verify that `/etc/128technology/pki/custom_ssr_peering.pem` exists on disk.
-  `ls -l /etc/128technology/pki/custom_ssr_peering.pem`
+3. Verify that `/etc/128technology/pki/my_peering_cert.pem` exists on disk.
+  `ls -l /etc/128technology/pki/my_peering_cert.pem`
 
 ### Activate the Certificate in Configuration
 
@@ -330,9 +351,9 @@ On the Conductor, configure `client-certificate` using the same `name` value use
 
 ```
 config authority
-    client-certificate  custom_ssr_peering
-        name             custom_ssr_peering
-        file             custom_ssr_peering
+    client-certificate  my_peering_cert
+        name             my_peering_cert
+        file             my_peering_cert
         validation-mode  strict
     exit
 exit

@@ -6,7 +6,8 @@ sidebar_label: Certificate-based Security Encryption
 
 | Release | Modification                | 
 | ------- | --------------------------- | 
-| 7.1.0   | Certificate-based Security Encryption support added. | 
+| 7.1.0   | Certificate-based Security Encryption support added. |
+| 7.2.0   | Subject Alternative Name support added to CSR generation. New audit events for certificate lifecycle. | 
 
 In addition to Enhanced Security Key Management, the SSR offers certificate based security encryption to encrypt, validate, and exchange certificates between devices within the network. 
 
@@ -191,7 +192,7 @@ Create the following file (updated to the customers algorithm/key size preferenc
 
 ```
 {
-    "name": "custom_ssr_peering", 
+    "name": "my_peering_cert", 
     "algorithm": "RSA",
     "rsa_key_size": "2048"
 }
@@ -206,19 +207,19 @@ curl -k -X POST https://10.27.35.89/api/v1/private-key
   -d @key_request.json
 ```
 
-Upon success, you can verify that the key was created by logging on to the SSR, `ssh` into a linux shell, and ensuring that `/etc/128technology/pki/custom_ssr_peering.key` exists on disk.
+Upon success, you can verify that the key was created by logging on to the SSR, `ssh` into a linux shell, and ensuring that `/etc/128technology/pki/my_peering_cert.key` exists on disk.
 
 ### Issue a `certificate-signing-request`
 
 In order to create a signed certificate by the CA for the SSR, the CA needs a `certificate-signing-request`. Instruct the SSR to create the request using the values provided; at a minimum the `name` and `common-name`. The SSR must sign the request with its private-key.
 
-1. Create a file that contains the body of the CSR-request. At a minimum this must include the name `custom_ssr_peering`, and the common name:
+1. Create a file that contains the body of the CSR-request. At a minimum this must include the `name` and the `common_name`:
 
 **csr_request.json**
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "common_name": "SSR_12345679"
 }
 ```
@@ -235,6 +236,7 @@ This example represents the minimum requirements. Any of the following additiona
 - rsa_key_size (integer, optional): The RSA key size. Only valid when algorithm is set to “RSA”. Valid key sizes are any multiple of 256 between 2048 and 4096.
 - ecc_curve (string, optional): The ECC curve to use. Only valid when algorithm is set to “ECC”.Valid curves are: (SECP256R, SECP384R1, SECP521R1)
 - validity_period (integer, optional): The validity period in days.
+- subject_alt_names (array, optional, SSR 7.2.0+): An array of Subject Alternative Name entries to include in the CSR. Each entry is an object with `type` and `value` fields. Supported types: `dns`, `ip`, `email`, `uri`, `urn_ssr_peering`. For details, see [Configure Certificate Management](config_custom_certs.md#issue-a-certificate-signing-request).
 
 2. Issue the CSR request to the SSR:
 
@@ -270,7 +272,7 @@ When the signed certificate is returned, instruct the SSR to ingest the certific
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "certificate": "-----BEGIN CERTIFICATE-----
 MIIF3DCCBESgAwIBAgIKAf9HQjJKSQd1lTANBgkqhkiG9w0BAQsFADBaMQswCQYD
 VQQGEwJERTERMA8GA1UECgwIT3BlblhQS0kxDDAKBgNVBAsMA1BLSTEqMCgGA1UE
@@ -288,8 +290,8 @@ Once the certificate is successfully ingested, verify that the certificate was a
 
 1. `ssh` to the SSR. 
 2. Log in as the root user: `sudo su`.
-3. Verify that `/etc/128technology/pki/custom_ssr_peering.pem` exists on disk.
-  `ls -l /etc/128technology/pki/custom_ssr_peering.pem`
+3. Verify that `/etc/128technology/pki/my_peering_cert.pem` exists on disk.
+  `ls -l /etc/128technology/pki/my_peering_cert.pem`
 
 ### Configure the Certificate
 
@@ -371,7 +373,20 @@ Audit events and logs are generated for the following events:
  Node:               test-1
  Description:        Generated CSR for: TestCertificate
  Json Event Detail:  {"name":"TestCertificate","common_name":"example.com","country_name":"US","state_province_name":"California","locality_name":"San
- Francisco","organization_name":"ExampleOrg","organizational_unit_name":"IT","email_address":"admin@example.com","validity_period_days":365}
+ Francisco","organization_name":"ExampleOrg","organizational_unit_name":"IT","email_address":"admin@example.com","validity_period_days":365,"subject_alt_names":[]}
+ Permitted:          True
+```
+
+- Generate Private Key
+
+```
+=======================================================================================================================================================
+ 2025-03-19T20:50:35.173Z Generated private key.
+=======================================================================================================================================================
+ Type:               system.generate_private_key
+ Node:               test-1
+ Description:        Generated private key for: TestCertificate
+ Json Event Detail:  {"name":"TestCertificate","algorithm":"RSA","rsa_key_size":2048}
  Permitted:          True
 ```
 
@@ -400,3 +415,55 @@ Audit events and logs are generated for the following events:
  GMT","crl_url":"http://10.27.39.143/testCrl.pem","size":14162,"total_entries":279,"added_entries":0,"removed_entries":0,"success":true,"certificate_authority":"/C=US/O=Google Trust Services/CN=WR2"}
  Permitted:          True
 ```
+
+- Update Certificate
+
+```
+=======================================================================================================================================================
+ 2025-03-26T21:22:43.108Z Updated a certificate.
+=======================================================================================================================================================
+ Type:               system.update_certificate
+ Node:               test-1
+ Description:        Updated certificate: TestCertificate
+ Json Event Detail:  {"purpose":"TLS Web Client Authentication","common_name":"example.com","crl_urls":[],"certificate_authority":"N/A","fingerprint":"6D:C7:8E:48:4F:55:63:D9:AB:70:66:CD:29:4E:1C:37:CF:89:17:B0"}
+ Permitted:          True
+```
+
+- Delete Certificate
+
+```
+=======================================================================================================================================================
+ 2025-03-26T21:22:43.108Z Deleted a certificate.
+=======================================================================================================================================================
+ Type:               system.delete_certificate
+ Node:               test-1
+ Description:        Deleted certificate: TestCertificate
+ Json Event Detail:  {"name":"TestCertificate"}
+ Permitted:          True
+```
+
+- Delete Private Key
+
+```
+=======================================================================================================================================================
+ 2025-03-26T21:22:43.108Z Deleted a private key.
+=======================================================================================================================================================
+ Type:               system.delete_private_key
+ Node:               test-1
+ Description:        Deleted private key: TestCertificate
+ Json Event Detail:  {"name":"TestCertificate"}
+ Permitted:          True
+```
+
+- Delete CSR
+
+```
+=======================================================================================================================================================
+ 2025-03-26T21:22:43.108Z Deleted a certificate signing request.
+=======================================================================================================================================================
+ Type:               system.delete_csr
+ Node:               test-1
+ Description:        Deleted CSR: TestCertificate
+ Json Event Detail:  {"name":"TestCertificate"}
+ Permitted:          True
+```