7.1.3-r2 documentation

docs/about_releases.md

@@ -35,7 +35,7 @@ However, issues resolved in `4.3.12`, which was released on 3/12/2021 are not ad
 
 | Version | Initial GA Version | First Release Shipping Date | Latest GA Version | End of Engineering support | End of Support |
 | -- | -- | -- | -- | -- | -- |
-| Release 7.1 | [7.1.0](release_notes_128t_7.1.md#release-710-50r1) | November 25, 2025 | [7.1.0](release_notes_128t_7.1.md#release-710-50r1) | September 4, 2026 | March 4, 2027 |
+| Release 7.1 | [7.1.0](release_notes_128t_7.1.md#release-710-50r1) | December 4, 2025 | [7.1.0](release_notes_128t_7.1.md#release-710-50r1) | September 4, 2026 | March 4, 2027 |
 | Release 7.0 | [7.0.1](release_notes_128t_7.0.md#release-701-1r1) | October 14, 2025 | [7.0.1](release_notes_128t_7.0.md#release-701-1r1) | July 14, 2026 | January 14, 2027 |
 | Release 6.3 | [6.3.0](release_notes_128t_6.3.md#release-630-107r1) | September 30, 2024 | [6.3.7-6-sts](release_notes_128t_6.3.md#release-637-6-sts) | May 6, 2026 | November 6, 2026 |
 | Release 6.2 | [6.2.0](release_notes_128t_6.2.md#release-620-39r1) | November 16, 2023 | [6.2.10-lts](release_notes_128t_6.2.md#release-6210-10-lts) | September 6, 2026 | March 6, 2027 |

docs/concept-tpm.md

@@ -0,0 +1,50 @@
+---
+title: Trusted Platform Module Overview
+sidebar_label: Trusted Platform Module 
+---
+
+#### Version History
+
+| Release | Modification                |
+| ------- | --------------------------- |
+| 7.1.3-r2   | Trusted Platform Module support added. |
+
+A Trusted Platform Module (TPM) is a secure cryptoprocessor that stores cryptographic keys. It serves as a secure storage mechanism for essential security artifacts such as digital certificates.
+
+## TPM-Based Certificates
+
+The SSR400 and SSR440 use the TPM-based certificate to ensure secure identification of the device. The device has a burnt-in idev-id certificate on the TPM. The idev-id certificate provides the device's Juniper serial number and model, proving that the device was manufactured in a Juniper facility. The TPM certificate is the most secure way for a Juniper device to prove its identity.
+
+### Benefits of TPM-Based Certificates
+
+- Provides trust. Helps to establish advanced security in an insecure digital world.
+- Provides confidentiality. Data sent is encrypted and only visible to the server and client.
+- Provides integrity. Ensures that the data has not been modified during the transfer.
+
+### How Does a Conventional SSL/TLS Certificate Work?
+
+Secure Socket Layer (SSL) is a protocol that allows encryption. It helps to secure and authenticate communications between a client and a server. It can also secure email, VoIP, and other communications over unsecured networks. SSL is also referred to as Transport Layer Security (TLS).
+
+In unsecured HTTP connections, hackers can easily intercept messages between client and server. SSL certificates use a public/private keypair system to initiate the HTTPS protocol. Hence, SSL certificates enable secure connections for users and clients to connect. SSL/TLS works through:
+
+- Secure communication that begins with a TLS handshake. The two communicating parties open a secure connection and exchange the public key.
+
+- During the TLS handshake, the two parties generate session keys. The session keys encrypt and decrypt all communications after the TLS handshake.
+
+- Different session keys encrypt communications in each new session.
+
+- TLS ensures that the user on the server side, or the website the user is interacting with, is who they claim.
+
+- TLS also ensures that data has not been altered, since a Message Authentication Code (MAC) is included with transmissions.
+
+When a signed SSL certificate secures a website, it proves that the organization has verified and authenticated its identity with the trusted third party. When the browser trusts the CA, the browser now trusts that organization’s identity too.
+
+For additional details on how SSR uses TPM, see [Configuration Integrity](concepts-config-integrity.md).
+
+### Support for vTPM on Conductor-managed Deployments
+
+If a vTPM is present on a platform, the SSR will first check to see if a trusted certificate and private key already exists. For Azure, AWS, and GCP it is expected that these platforms generate their own keys and certificates. On other platforms, if no certificate and private key is present, a single `DevID` certificate and `master` private key are created and stored in the vTPM.
+
+Each certificate installed on the system is signed with a uniquely created private key pair and stored on disk, encrypted with the master key stored in the vTPM.
+
+

docs/concepts-config-integrity.md

@@ -0,0 +1,86 @@
+---
+title: Configuration Integrity
+sidebar_label: Configuration Integrity
+--- 
+
+#### Version History
+
+| Release | Modification                |
+| ------- | --------------------------- |
+| 7.1.3   | SSR Configuration Integrity added. |
+
+SSR Configuration Integrity addresses security requirements for protecting sensitive data stored on SSR devices when they are at rest - when a system is powered off for extended periods, physically stolen, or have their storage media removed and analyzed offline by malicious actors seeking to extract sensitive information or compromise network security. 
+
+SSR devices are frequently deployed in environments where physical security cannot be guaranteed, ranging from remote branch offices and retail locations to temporary installations and field deployments. In these environments, configuration files, private keys, and operational data stored on the device require protection from unauthorized access. 
+
+Modern compliance requirements and regulatory frameworks mandate encryption-at-rest for sensitive data, particularly in the financial services, healthcare, and government sectors. High-security customers require robust protection against data exfiltration to maintain their security posture and meet regulatory obligations. These requirements have evolved beyond simple access controls to demand cryptographic protection of stored credentials, configuration data, and private key material that could be exploited to compromise broader network infrastructure.
+
+SSR Configuration Integrity protects authentication credentials, keys and certificates, network topology information, and other pieces of sensitive SSR configuration from unauthorized access when the system is powered off.
+
+Furthermore, Configuration Integrity prevents network and SSR operations from executing when the system is determined to be in a compromised state. These protected secrets cannot be exfiltrated even if the bad actor has physical access to the drive, preventing attackers from impersonating network nodes or intercepting encrypted communications. Most importantly, it meets compliance requirements for encryption-at-rest without impacting runtime performance, allowing organizations to satisfy regulatory mandates while maintaining the high-performance networking capabilities that SSR devices are designed to provide.
+
+Configuration Integrity does not address any runtime access-policy or permissions concerns. Proper file and directory permissions are still required, as well as proper login and authentication controls. Configuration Integrity augments the existing SSR security functionality to provide encryption-at-rest guarantees. 
+
+Configuration Integrity is enabled by default on new installations of, and upgrades to, SSR 7.1.3-r2. 
+
+## How It Works
+
+Configuration Integrity utilizes a hybrid approach combining TPM2 hardware security with Linux native filesystem encryption, administered by the userspace tool fscrypt. fscrypt utilizes an AES-256 key generated and protected by the TPM to perform encryption and decryption operations. Once the encrypted directories are unlocked, they operate as a normal directory; the encryption is transparent to the user.
+
+### Major Components
+
+The following are the major components of Configuration Integrity. 
+
+### TPM2 Hardware Security Module
+
+The TPM is the trust anchor of the system. It creates and unseals the Filesystem Encryption Key (FEK), and is the only component of the system that can perform this task. If the storage of the SSR is somehow separated from the TPM, the FEK can no longer be unsealed, and the filesystem cannot be unlocked, ensuring that sensitive data remains protected.  
+
+All SSR TPMs are provisioned with an RSA-2048 key, which is used to perform the encryption and decryption of the FEK.
+
+### Filesystem Encryption Key (FEK)
+
+The FEK is a 256-bit random number generated by the TPM. Once it has been generated, it is encrypted by the TPM using RSA-2048 before being written to disk. At no time will the unencrypted FEK be written on disk. Any time it is decrypted, it is stored in memory only.
+
+### fscrypt 
+
+fscrypt is a userspace interface to the Kernel-level filesystem and encryption stacks. It operates on a per-directory basis, leveraging either a PAM module, a passphrase, or a 256-bit raw key to unlock and decrypt the directory. The SSR uses only the raw key mode.
+
+fscrypt requires that no target directory exist as a repository for decrypted files. Because technology allows the recovery of deleted files from a directory, the process of migrating files to an existing encrypted directory leaves traces of the unencrypted versions on disk resulting in a potential security risk. 
+
+All sensitive files will be written to the encrypted directory from their inception onward, ensuring that there is no security risk. fscrypt configured in raw_key mode uses AES-256-XTS encryption for file contents and AES-256-CBC-CTS encryption for filenames. 
+
+### Configuration Integrity Systemd Service
+
+The Integrity Handler is the systemd service responsible for Configuration Integrity on the system. If it detects that a system has not been configured for Configuration Integrity, it will perform a series of checks to see if it can support the feature. If the system can support the feature, it will onboard the system into Configuration Integrity.
+
+Once a system is onboarded, the Integrity Handler is responsible for unlocking the encrypted directories so they can be transparently used by the system. It does so with the following sequence:
+
+1.	Locate encrypted FEK on disk.
+2.	Unseal FEK with the TPM.
+3.	Pass unencrypted FEK to fscrypt.
+4.	fscrypt uses the FEK to automatically unlock the necessary encrypted directories.
+
+If any of these steps fail, it is interpreted as an integrity event. Network activities are blocked. An emergency log is generated and broadcast to all consoles on the system that the system integrity is compromised and it must be reprovisioned. The SSR will repeatedly try to start the integrity service to unlock the encrypted directories and fail, each time writing the emergency log. 
+
+```
+Broadcast message from systemd-journald@TESTsystem1 (Mon 2025-12-01 17:15:20 UTC):
+
+integrity-handler: Integrity event detected. A clean installation is required.
+```
+
+Recovery steps require physical access to the device to [reimage the system with a fresh ISO](intro_installation_univ-iso.md).
+
+## Troubleshooting
+
+Use the information below to investigate issues and understand the Configuration Integrity feature.
+
+### Logging
+
+Logging is handled through existing system components rather than a dedicated log category. During initial system provisioning, all Configuration Integrity initialization is logged as part of the standard provisioning process. On subsequent boots, the systemd service that is responsible for unlocking encrypted directories logs all unlock operations and service status information through the systemd journal. Use `journalctl -u integrity-handler` for visibility into the operational state of the encryption system during the boot sequence.
+
+Key operational messages include TPM provisioning status and error conditions, filesystem encryption capability detection results, and detailed logging of FEK generation, storage, and retrieval operations. The system also logs all directory encryption and decryption operations along with integrity violation events that may trigger protective responses. 
+
+### Compromised System
+
+In the event your system has been compromised, the device must be reprovisioned with a [clean install from a bootable USB](intro_installation_univ-iso.md). If that is not viable, contact your sales team or Juniper technical support to begin the RMA process. 
+

docs/config-custom-certs.md

@@ -166,7 +166,7 @@ Store the value of the token in a file called `token.txt` for use later.
 ### Issue a Private-key Creation Request
 
 :::important
-It is necessary for all of the following 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 Managementin 7.0. This is a reserved name specifically used by Enhanced Security Key Management.
+It is necessary for all of the following 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 Enhanced Security Key Management.
 :::
 
 The goal of this workflow is to ensure that the private key of the SSR never leaves the SSR. To do so, we need to instruct the SSR to create a private key. To accomplish this, we provide the SSR some details, including: