docs: add SAN URI peering identity support for SSR 7.2.0#1016
Open
madamsJuniper wants to merge 2 commits into
Open
docs: add SAN URI peering identity support for SSR 7.2.0#1016madamsJuniper wants to merge 2 commits into
madamsJuniper wants to merge 2 commits into
Conversation
- Add subject_alt_names parameter to CSR API documentation - Document urn:ssr:peering SAN URI for SVRv2 peer identity - Highlight HA use case: unique CNs per node with shared SAN URI - Update peer authentication flow: CN check then SAN URI fallback - Replace custom_ssr_peering with my_peering_cert in examples - Add legacy note for custom_ssr_peering disk-based fallback - Add 5 new audit event types (generate/delete private key, update/delete certificate, delete CSR) - Update generate_csr audit event with subject_alt_names field - Remove role parameter references (removed in PR #20519) Refs: ssr#20819, ssr#20767, ssr#20519
madamsJuniper
requested review from
Chr1st0ph3rTurn3r and
MichaelBaj
as code owners
plessard128
reviewed
May 15, 2026
| | `common_name` (in CSR request) | Per-router / per-node | **Must be unique per router or HA node**, and must **exactly match** that router's configured `peering-common-name`. | | ||
| | `peering-common-name` (in config) | Per-router | Unique alias per router. Must match the `common_name` used in that router's CSR. | | ||
| | `name` (in all API requests) | Authority-wide | **Must be identical across all routers and nodes.** In SSR 7.1+, any consistent name may be used. | | ||
| | `common_name` (in CSR request) | Per-router / per-node | **Must be unique per router or HA node.** Must match the router's configured `peering-common-name` — either directly in the `common_name` field, or via a `urn:ssr:peering` SAN URI (see below). | |
Contributor
There was a problem hiding this comment.
Must match the router's configured
peering-common-name— either directly in thecommon_namefield, or via aurn:ssr:peeringSAN URI (see below).
This seems a bit misleading to me. If they are using a peering SAN, then the common name explicitly does not need to match the peering-common-name
MichaelBaj
requested changes
May 15, 2026
| | --- | --- | | ||
| | 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 SVRv2 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. | |
Contributor
There was a problem hiding this comment.
Please change "SVRv2" to "SVR"
Chr1st0ph3rTurn3r
requested changes
May 15, 2026
|
|
||
| 1. **Common Name (CN) check** — if the certificate's CN matches the peer's `peering-common-name`, the certificate is accepted. | ||
| 2. **SAN URI fallback (SSR 7.2.0+)** — if the CN does not match, the SSR checks for a `urn:ssr:peering:<peering-common-name>` SAN URI in the certificate's Subject Alternative Name extension. If found, the certificate is accepted. | ||
| 3. **Rejection** — if neither the CN nor any SAN URI matches, the certificate is rejected. The behavior depends on the `invalid-certificate-behavior` setting (`fail-soft` or `fail-hard`). |
Contributor
There was a problem hiding this comment.
Suggest: Remove "The behavior depends on the invalid-certificate-behavior setting (fail-soft or fail-hard)."
Replace with:
How the SSR handles the certificate rejection is defined using the the invalid-certificate-behavior setting (fail-soft or fail-hard).
Chr1st0ph3rTurn3r
approved these changes
May 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Certificates can now carry SVRv2 peering identity via a urn:ssr:peering: SAN URI, allowing the Common Name to be used for other purposes. This is especially useful in HA deployments where both nodes share a peering-common-name but enterprise PKI policies require unique CNs per certificate. The SSR checks the CN first and falls back to the SAN URI for peer identity verification.
Full list of documentation changes:
Refs: SSR PRs #20819, #20767, #20519