# mulesoft Security - Full Documentation --- product: Security version: master --- # Add a Certificate > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Add a Privacy-Enhanced Mail (PEM) certificate to your secret group to use a Base64-encoded DER certificate. This certificate is the "leaf" (end-entity) certificate. 1. In the Secret Groups list view, select the secret group you need to add a certificate to and click **Edit**. 2. In the menu on the left, select **Certificate** and then click **Add Certificate**. 3. In the **Add Certificate** screen, complete these fields: - **Name** Enter a name for your certificate. - **Type** Select **PEM** from the drop-down menu. - **Certificate File** Click **Choose File** and select the certificate file to upload. - **Override Expiration Date** If you want to override the current expiration date of the certificate, select a new expiration date. 4. Click **Save**. ## See Also - [Create a Secret Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task) - [Add a TLS Context](https://docs.mulesoft.com/anypoint-security/secret-group-add-tls-context) --- product: Security version: master --- # Add a TLS Context for Anypoint Runtime Fabric (Advanced Configuration) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If your environment requires advanced configuration such as client authentication (mutual authentication), selecting ciphers, and selecting TLS versions, you can import a TLS context from the secrets manager. ## See Also - [Enable Client Authentication](https://docs.mulesoft.com/anypoint-security/enable-client-authentication) - [Cipher Suites](https://docs.mulesoft.com/anypoint-security/cipher-suites) - [Supported Secret Types](https://docs.mulesoft.com/anypoint-security/asm-secret-type-support-reference) --- product: Security version: master --- # Add a TLS Context to Mule > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you create a secret group, you can add a Transport Layer Security (TLS) context to encrypt inbound traffic to Mule 4 proxies. When you add the TLS context, you can select the ciphers to use with the TLS context. You can use the TLS context you store in the secrets manager when you configure an HTTPS API proxy. ## Add TLS Context Adding a TLS context to your secret group involves supplying a name, target, security information, version, keystore and, optionally, truststore. 1. In the **Secret Groups** list view, select the secret group to which to add a TLS context. 2. Select **TLS Context** in the menu on the left, and click **Add TLS Context**. 3. In the Create TLS Context screen, add the required information: - **Name** Enter a name for your TLS context. - **Target** Select **Mule** to use the TLS context as the SSL validation for Mule 4-based API proxies. Uses the TLS context as the SSL validation for Mule 4-based API proxies. - **TLS Version** By default, TLS 1.3 is selected. You can select TLS 1.2 to support both versions. - **Keystore** From the drop-down list, select the keystore associated with the TLS context. - **Truststore** Optionally, select a truststore associated with the TLS context if you are using a truststore to store certificates trusted by the client. If the Target value for the TLS context is **Mule**, you can select **Insecure** if you don’t want certificate validation enforced. - **Expiration Date** Optionally, select the expiration date for the TLS context. The information is considered as metadata of the TLS context. The expiry date of the certificates in the associated keystore or truststore doesn’t change. 4. Optionally, [select ciphers](https://docs.mulesoft.com/anypoint-security/cipher-suites) for the TLS context. 5. Click **Save**. ## See Also - [Create a Secret Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task) --- product: Security version: master --- # Anypoint Platform Secrets Manager Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Organization administrators assign Secrets Manager permissions in Access Management. Each permission applies to a specific Anypoint environment. ## User Permissions Grant these permissions to control who can create secret groups, manage secrets, and connect external vaults.
Required PermissionsGrants the Ability toNotes

Grant access to secrets

Browse, read metadata and grant access to secrets in a specific environment.

Manage secret groups

  • Create, modify, delete, read, and clone secret groups in a specific environment.

  • Check if the user can initiate a new clone or restore operation.

Read secrets metadata

Browse and read metadata of secrets in a specific environment.

Write secrets

Upload, create, modify secrets in a specific environment.

View Vault Integrations

List and view external vault integrations and their sync activity and health checks in a specific environment.

This permission applies only to the enhanced experience.

Manage Vault Integrations

Create, edit, delete, test, and sync external vault integrations in a specific environment. Extends the View Vault Integrations permission.

This permission applies only to the enhanced experience.

## See Also - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) - [Secret Groups](https://docs.mulesoft.com/anypoint-security/asm-secret-group-concept) --- product: Security version: master --- # Anypoint Security Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Security for Anypoint Runtime Fabric provides a layered approach to secure your application network. These layers work together to protect both the application network and the network’s individual nodes by controlling access to APIs, enforcing policies, and proxying all inbound or outbound traffic to mitigate external threats and attacks. Anypoint Security also provides you with a dedicated endpoint to detect attacks and validate traffic without taxing your network implementations. ![Mule apps in Runtime Fabric protected by the request endpoint with TLS validation](/mulesoft/current/en-us/anypoint-security/_images/index-1c19d.png) > [!NOTE] Anypoint Security requires a separate license. Contact your MuleSoft account > representative for more information. ## Secrets Manager Anypoint Security provides a secure vault for you to store the TLS certificates and keystores used by your deployments. Through Secrets Manager, you can store the necessary secrets to set up the TLS context that encrypts inbound traffic to your Runtime Fabric. ## See Also - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) --- product: Security version: master --- # Anypoint Security Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Security provides a layered approach to secure your application network. These layers work together to protect both the application network and its individual nodes by controlling access to APIs, enforcing policies, and proxying all inbound or outbound traffic to mitigate external threats. These capabilities are optimized for security, providing you with a dedicated endpoint to detect attacks and validate traffic without taxing your implementations. These release notes apply to Anypoint Security: - [Secrets Manager Release Notes](https://docs.mulesoft.com/release-notes/anypoint-security/secrets-manager-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Security version: master --- # Anypoint Security Secrets Manager Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Security secrets manager securely stores and controls access to keys, certificates, passwords, and other secrets. Centralize secret management, enforce least‑privilege access, and enable trusted platform services to consume secrets on your behalf. Prevent hard‑coding sensitive data and streamline security operations across Anypoint Platform. > [!NOTE] If you can’t access the secrets manager or you receive an error saying > `Cannot Create Secret Groups`, you must add the correct permissions in Access Management: > > - If you need access only to secrets manager and don’t manage instances of Anypoint Runtime > Fabric, add the appropriate user permissions in **Access Management > Permissions > Secrets > Manager**. > > - If you manage instances of Runtime Fabric, add only the **Manage Runtime Fabric** permission > (you don’t need to add the **Secrets Manager** permission separately). Use secrets manager to write and manage your secrets, keys, and Transport Layer Security (TLS) artifacts. You can read the metadata of the secrets, but the actual secrets can be consumed only by authorized platform services on your behalf. Secrets manager is designed to store and manage secrets for supported Anypoint Platform services. It’s not a general-purpose storage for secrets. Only trusted services within Anypoint Platform have access to the contents of the secret. Secrets manager supports the management of TLS context for these services: - Runtime Fabric ingress You can store TLS artifacts in secrets manager and then configure Anypoint Runtime Fabric ingress with the secret reference. Secrets manager supports Runtime Fabric ingress only for Runtime Fabric on VM/Bare Metal (Appliance). - API Manager on Anypoint Platform You can store the TLS artifacts in secrets manager and then configure Anypoint API Manager with the secret reference. See [Building an HTTPS API Proxy](https://docs.mulesoft.com/api-manager/latest/building-https-proxy). Secrets manager enables you to store secrets in secrets groups, which are vaults associated with your environment and business group. Each secrets group has unique encryption keys, which are generated and managed only by secrets manager. You can configure the supported Anypoint Platform services to request secrets stored in secrets manager, and you can control which supported services are authorized to access them. This task is handled by two microservices: - Secrets manager This is a publicly exposed service that handles the uploading and storing of your secrets. Every time you upload a secret to your vault, the secrets manager establishes a reference to it, so it can be shared or read without revealing its contents. You can read the secrets metadata but not the secret itself. - Secrets Provider This is an internal service that handles the secrets for consumption by supported platform services. This is the only service that can read the actual secrets and due to its nature, it’s not accessible from the public network. ![Diagram showing how secrets manager interacts with the secrets provider service and Anypoint Platform services.](/mulesoft/current/en-us/anypoint-security/_images/secrets-manager-diagram.png) ## Supported Secret Types Secrets manager can store and manage these secret types: - TLS Context SSL Security Parameters (ciphers to use, TLS version, and so on). - Keystore A repository of security certificates (either authorization certificates or public key certificates), along with their corresponding private keys. - Truststore A repository of security certificates from either other parties with which you expect to communicate, or Certificate Authorities that you trust to identify other parties. - Certificates Public X.509 certificates, which are electronic documents that bind a public key with an identity (hostname, organization, or individual). - Certificate Pin Set A repository of security certificates from other parties that associate a client or host with their expected X.509 certificate or public key. - CRL Distributor An entity that creates and maintains a list of CA certificates that are no longer trusted because their associated private keys, or a signing CA, were compromised. ### Limitations - A maximum of 25 secret groups per environment per business group are allowed. - Each secret group can contain a maximum of 350 secrets. - Shared secrets are used for symmetric encryption and decryption, where the secret is known by both the message sender and the message recipient. These shared secret types are defined, however, Anypoint Platform services can’t consume them: - Passwords A password used by the sender and recipient to encode and decode the message. - Symmetric Keys A public key cryptography used by the sender and recipient to encode and decode the message. - S3 Credentials A pair of security keys to access AWS S3 buckets. - Blob A free-form and application-specific secret stored through an API call. Blobs are base64-encoded data used by specific applications. For example, a blob can store a base64-encoded JSON object. ## See Also - [Supported Secret Types Reference](https://docs.mulesoft.com/anypoint-security/asm-secret-type-support-reference) - [Secret Groups](https://docs.mulesoft.com/anypoint-security/asm-secret-group-concept) - [Secrets Manager Permissions](https://docs.mulesoft.com/anypoint-security/asm-permission-concept) - [Building an HTTPS API Proxy](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) --- product: Security version: master --- # Cipher Suites > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When you configure a TLS context, default ciphers are applied to it based on the TLS version you selected. If you don’t use the defaults, you can select ciphers that match the configured keystore to ensure that TLS can set up a connection: - For a keystore with an RSA key (the most common type), select ciphers that contain the string `RSA`. - If you are using ECC ciphers, select ciphers that contain the string `ECDSA`. Consult TLS standards and documentation for more information. - If a client device supports AES-dedicated CPU instructions, use the AES-GCM ciphers. If the client does not support AES-dedicated instructions (some mobile and IoT devices), the client negotiates to use `CHACHA20-POLY1305`. It takes two (client and server) to perform the CHACHA. ## TLS 1.3 Cipher Suites TLS 1.3 support is available only if you are using the **Anypoint Security** target. The cipher suites for TLS 1.3 are listed with those of TLS 1.2 and TLS 1.1 and appear in the **No known vulnerabilities and support Perfect Forward Secrecy** grouping. When you use cipher suites that start with the string `TLS`, keep in mind the following: - The new cipher suites for TLS 1.3 cannot be used with TLS 1.1 and TLS 1.2. - The cipher suites for TLS 1.2 and TLS 1.1 cannot be used for TLS 1.3. - The new cipher suites for TLS 1.3 are defined differently from the cipher suites for earlier versions of TLS and do not specify the certificate type (for example, RSA, DSA, ECDSA) or the key exchange mechanism (for example, DHE or ECHDE). ## Select Ciphers In addition to the defaults, you can select other ciphers to use with the selected TLS version. Each TLS context can have multiple ciphers. 1. Click **Ciphers** to select available ciphers. If you select a **TLS Version** value of **TLS 1.3**, keep the default selection, which includes all three of the TLS cipher suites. 2. If you selected **Mule** as the **Target** value for the TLS context, you can define custom ciphers to use with your proxy instance. 3. Click **Save**. If you add a cipher that’s not supported by the Java runtime, you receive a warning, but this does not prevent you from saving the TLS context. ## TLS Support on Anypoint Runtime Fabric The TLS 1.3 protocol is enabled by default for those clients that support it. OpenSSL 1.1.1 and TLS 1.3 provide the following security enhancements and performance improvements over TLS 1.2: - Double or more than double TLS 1.2 connection performance throughput boost over an earlier Runtime Fabric internal load balancer running on OpenSSL 1.0.2 - Reduction of one round trip in a full handshake - Added TLS 1.2 and TLS 1.3 ChaCha20-Poly1305 ciphers for better mobile and IoT device support - Protection against downgrade attacks - Continued support for both RSA and ECDSA keys - Removal of obsolete and insecure features from TLS 1.2 and TLS 1.1. ## See Also - [Add a TLS Context for Mule](https://docs.mulesoft.com/anypoint-security/secret-group-add-tls-context) - [Configure a TLS Context for Runtime Fabric Load Balancer](https://docs.mulesoft.com/anypoint-security/configure-tls-context-rtf-lb) --- product: Security version: master --- # Create and Edit Secret Groups (Anypoint Platform) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secrets Manager enables you to create and edit secrets groups, which is a logical grouping of secrets. Secrets Manager also enables you to create new secret types and add them to a secrets group. > [!NOTE] A maximum of 25 secret groups are allowed per environment per business group. Each secret > group can contain a maximum of 350 secrets. ## Prerequisites To create and edit secret groups: - Verify that you have the `Write secrets` permission in Access Management. - Verify that you’re in the correct environment using the environment or business group. ## Create a Secret Group 1. In Anypoint Platform, go to **Management Center > Secrets Manager**. 2. Select **Create Secret Group**. 3. Enter a name for the secret group that: - Starts with a letter - Is at least three characters long and no longer than 35 characters - Contains only letters, numbers, and dashes; however, the name can’t end with a dash. 4. Select **Secret Group Downloadable** to allow authenticated users to download secrets outside of Anypoint Platform. > [!NOTE] If you select this option, secrets can be downloaded over public networks. Next, add the secret types to the secret group. ## Add a Truststore Add a truststore for public certificates of trusted servers. The truststore stores up to 15 certificates from the trusted CA, which are then used to verify certificates presented by the server in an SSL connection. 1. In the Secret Groups list view, select the secret group to add the truststore to, and click **Edit**. 2. Select **Truststore** > **Add Truststore**. 3. In **Add Truststore**, add the required information: - **Name** Enter a name for your truststore. - **Type** Select the truststore type: **PEM** JKS **PKCS12** JCEKS - **Truststore File** Click **Choose File** and select the truststore file to upload. - **Override Expiration Date** Select the date to override the default expiration date of the certificate. > [!NOTE] If you’re uploading a JKS, PKCS12, or JCEKS truststore file, you must also provide > the passphrase for this truststore. 4. Click **Save**. ## Add a Keystore Specify the type of keystore to add to the secret group. The keystore is the combination of the authorization certificate, its corresponding private keys, and the certification authority’s path. 1. In the **Secret Groups** list view, select the secret group to add a keystore to, and click **Edit**. 2. Select **Keystore** > **Add Keystore**. 3. In the **Name** field, enter a name for the keystore. 4. In the **Type** field, select the keystore type. Supported types include: - Privacy-Enhanced Mail (PEM) Base64-encoded ASCII file with a `cer`, `crt`, or `pem` extension - Java Keystore (JKS) Repository for authorization or public key certificates. The JKS keystore type doesn’t store secret keys. - PKCS #12 Stores server and intermediate certificates in an archive file format. The PKCS #12 keystore type doesn’t store secret keys. > [!NOTE] Some PKCS12 files generated with newer OpenSSL defaults (AES/SHA-256) might not > upload and can return `RB-1003: invalid content`. If upload fails, generate the PKCS12 file > with Java `keytool` or use OpenSSL legacy PKCS12 settings for broader compatibility. This > approach helps ensure that Secrets Manager can parse the keystore successfully. - Java Cryptography Extension keystore (JCEKS) Stores server and intermediate certificates as well as secret keys. - To add a **PEM** type keystore, you must provide: - **Certificate File** Click **Choose File** to locate and upload the PEM certificate file. - **Key File** Click **Choose File** to locate and upload the PEM-formatted file that contains the private key for the certificate. - **Key Passphrase** Enter the word or phrase that protects the private key. - **CA Path Certificate File** Click **Choose File** to locate and upload the certificate signed by a certification authority (CA). The CA path contains the intermediary and root certificates that are related to the certificate file to use. - **Override Expiration Date** Select the date to override the default expiration date of the certificate. - To add a **JKS**, **PKCS12**, or **JCEKS** type keystore, you must provide: - **Keystore File** Click **Choose File** to locate and upload the keystore file to use. - **Keystore Passphrase** Enter the word or phrase that protects the keystore. - **Alias** The alias used to access the keystore entries (key and trusted certificate entries). - **Key Passphrase** The word or phrase that protects the private key. - **Algorithm** The algorithm to use for encryption of keys. - **Override Expiration Date** Select the date to override the current expiration date of the certificate. 5. Click **Save**. ## Add a Certificate Pinset Add a concatenated list of PEM certificates to the secret group. 1. In the **Secret Groups** list view, select the secret group to add a certificate pinset to, and click **Edit**. 2. Select **Certificate Pinset** > **Add Certificate Pinset**. 3. In the **Certificate Pinset** screen, add the required information. - **Name** Enter a name for the certificate pinset. - **Certificate File** Click **Choose File** and select the PEM formatted CA certificate to upload. - **Expiration Date** Select the expiration date for the certificate. 4. Click **Save**. ## Add a Shared Secret Add a secret users can share for authentication. 1. In the **Secret Groups** list view, select the secret group to add a shared secret to, and click **Edit**. 2. Select **Shared Secret** > **Add Shared Secret**. 3. In the **Add Shared Secret** screen, add the required information: - **Name** Enter a name for your shared secret. - **Type**: - **Username Password** Provide a username and password. - **Symmetric Key** Provide a Base64 string containing symmetric key. - **S3 Credential** Provide the access key ID and the secret access key to an S3 bucket. - **Blob** Provide a Base64-encoded value. 4. Click **Save**. ## Edit a Secret Group Edit a secrets group to add secret types such as keystores, truststores, certificates, etc. 1. In the **Secret Groups** list view, select the secret group you want to edit, then click **Edit**. 2. Make changes to the secrets as required. As you create or save changes to a secret, the changes are applied immediately. The updated secret group is immediately available the next time the secret group is accessed or when deploying an application. ## See Also - [Add a TLS Context for Mule](https://docs.mulesoft.com/anypoint-security/secret-group-add-tls-context) - [Secrets Manager Permissions](https://docs.mulesoft.com/anypoint-security/asm-permission-concept) - [Supported Secret Types Reference](https://docs.mulesoft.com/anypoint-security/asm-secret-type-support-reference) - [Build an HTTPS API Proxy](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) --- product: Security version: master --- # Enable Client Authentication > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you choose a target value of **Anypoint Security** when adding your TLS context, you can optionally enable client authentication. TLS-enabled clients verify that they trust the server by validating the public certificate against their own set of trusted certificates. A truststore to store certificates trusted by the client is required if you are enabling client authentication for the TLS context. To enable client authentication: 1. In the Create TLS Context page for the secrets group, select **Enable Client Authentication** and provide the following information: - **Verification Depth** Select the maximum depth to allow for the certificate chain verification. - **Revocation Method** - **Send Trust Store** Select this option if you want the inbound load balancer to send the truststore to the far-end client for mutual TLS. Clients use the truststore to select the correct certificate and path to use in cases where a client has multiple certificates and paths provisioned. - **Perform Certificate Pinning** Select this option if you want to allow access only for client certificates that are present in the selected certificate pinning list. In this case, a client certificate must have a chain of trust to a certificate (usually a CA) that appears in the truststore but also must be explicitly present (pinned) in the selected certificate pinning list. 2. Click **Advanced Options** to expand the available options, and select the options to enable: - **Certificate Checking Strength** This option allows the application to control whether strict or lax certificate checking is performed during chain-of-trust processing. Lax certificate checking offers more flexibility because of its less rigorous verification process, but it comes with a higher risk of accepting potentially compromised or fraudulent certificates. Strict certificate checking has more rigorous requirements for certificate validity and revocation checking, which demands more computational resources. - **Certificate Policy Checking** Controls certificate policy processing as defined in RFC 3280 and 5280. A certificate can contain zero or more policies. A policy is represented as an object identifier (OID). In an end-entity certificate, this policy information indicates the policy under which the certificate has been issued and the purposes for which the certificate can be used. In a CA certificate, this policy information limits the set of policies for certification paths that include this certificate. Applications with specific policy requirements are expected to have a list of those policies that they will accept and to compare the policy OIDs in the certificate to that list. If this extension is critical, the path validation software must be able to interpret this extension (including the optional qualifier), or must reject the certificate. - **OID** Select the object identifier options, which include: - **Require Initial Explicit Policy** Indicates that the path must be valid for at least one of the certificate policies in the `user-initial-policy-set`. - **Certificate Policies** At minimum, consists of a policy identifier (OID). - **Authentication Overrides** Select the criteria for when to override failing authentication when mutual authentication is performed. 3. Click **Save**. ## See Also - [Configure a TLS Context for Runtime Fabric Load Balancer](https://docs.mulesoft.com/anypoint-security/configure-tls-context-rtf-lb) - [Cipher Suites](https://docs.mulesoft.com/anypoint-security/cipher-suites) --- product: Security version: master --- # Secret Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A _secret group_ is a logical grouping of secrets that enables you to manage a group of secrets as a unit. Secrets Manager stores your secrets per secret group, per environment, and per business group. > [!NOTE] A maximum of 25 secret groups are allowed per environment per business group. Each secret > group can contain a maximum of 350 secrets. User access and authorization controls are applied at the environment level. A user who has access on a given environment can access all the secret groups that belong to that environment. Only applications deployed to those specific business groups and environments within your organization can access the secrets stored in each secret group. ## See Also - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) - [Secrets Manager Permissions](https://docs.mulesoft.com/anypoint-security/asm-permission-concept) - [Create and Edit a Secret Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task) --- product: Security version: master --- # Supported Secret Types Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt ## Simple Secret Types
Secret TypeDescription

Shared Secret

This security object contains a username and password or a base64-encoded symmetric key.
The shared secret is used for symmetric encryption and decryption in situations in which the secret is known by both the message sender and the message recipient. The sender uses the key to encrypt and sign the message. The recipient uses the key to decrypt the message and verify a message’s digital signature.

The secrets manager enables an administrator to define one of a static username and password combination, a static symmetric key, an S3 bucket, or blobs.

Certificate

This security object contains an X.509 certificate and an electronic document that uses a digital signature to bind a public key with an identity.
The secrets manager supports PEM and JKS certificates.

## Secret Types Used in TLS and SSL Communication
Secret TypeDescription

Keystore

A keystore is a repository of security certificates (either authorization certificates or public key certificates), plus corresponding private keys used, for example, in SSL encryption.

Secrets manager accepts both keys and certificates signed by RSA and EdDSA (ED448 and ED25519).

Supported keystore types are:

  • JKS

  • JCEKS

  • PEM

  • PKCS12

Truststore

A truststore is a repository of security certificates from other parties with which you expect to communicate, or from Certificate Authorities that you trust to identify other parties.

Secrets manager accepts truststores with expired certificates.

The secrets manager truststore accepts the following standard input formats:

  • PEM

  • JKS

  • PKCS12

  • JCEKS

Certificate Pinset

A Certificate Pinset is a repository of security certificates from other parties that associate a client or host with their expected X.509 certificate or public key. These security certificate identities are then "pinned" to clients or hosts.
This repository or "Pin Set" acts as a list of certificates that can be used, for example, to identify clients in a SSL/TLS connection. The secrets manager accepts a concatenated list of PEM certificates as input.

TLS Context

This security object defines all SSL critical security parameters.

## See Also - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) - [Secret Groups](https://docs.mulesoft.com/anypoint-security/asm-secret-group-concept) - [Secrets Manager Permissions](https://docs.mulesoft.com/anypoint-security/asm-permission-concept)