InboundCertificate Metadata Type in SFDX

Architectural Overview#

InboundCertificate represents a public X.509 cryptographic certificate imported into Salesforce to authenticate inbound connections. Unlike outbound certificates (which hold private keys used by Salesforce to sign requests or establish TLS sessions to external servers), InboundCertificate holds public certificates presented by external systems.

Its primary architectural use cases include mutual TLS (mTLS) authentication on port 8443, validating signed SAML authentication requests, and verifying XML or JWT digital signatures from enterprise API gateways. Managing InboundCertificate metadata via version control allows automated lifecycle management of corporate public key infrastructure (PKI).

Directory and File Conventions#

InboundCertificate files are stored in the inboundCertificates directory:

Key Metadata Fields#

The XML schema for InboundCertificate defines public certificate properties:

Declarative XML and Package Manifest Examples#

Below is an illustrative InboundCertificate metadata file:

<?xml version="1.0" encoding="UTF-8"?>
<InboundCertificate xmlns="http://soap.sforce.com/2006/04/metadata">
    <masterLabel>Payment Gateway mTLS Certificate</masterLabel>
    <description>Public X.509 certificate for inbound API mutual TLS verification</description>
    <content>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3f...</content>
</InboundCertificate>

Package Manifest (package.xml)#

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Payment_Gateway_mTLS</members>
        <name>InboundCertificate</name>
    </types>
    <version>68.0</version>
</Package>

Retrieval and Deployment via SF CLI#

Retrieve and deploy inbound certificates:

# Retrieve an inbound certificate
sf project retrieve start --metadata "InboundCertificate:Payment_Gateway_mTLS"

# Deploy inbound certificates to sandbox
sf project deploy start --metadata "InboundCertificate" --target-org dev-org

Senior Architect Best Practices and Gotchas#

• Expiration Rotation Planning: Rotate certificates 30–60 days before expiration. Because mTLS blocks handshakes immediately upon expiration, plan overlapping dual-certificate trust windows.
• Base64 Formatting: Ensure base64 certificate content strings are sanitized of carriage returns or unwanted header/footer delimiters (-----BEGIN CERTIFICATE-----) when embedding in XML.
• Port 8443 Enforcement: Inbound mutual TLS requires external API clients to connect to the dedicated Salesforce mutual authentication domain on port 8443 (https://mycompany.my.salesforce.com:8443).

Frequently asked questions

What is the primary role of InboundCertificate?

It imports and stores public X.509 certificates for mutual TLS authentication and digital signature verification.

Does InboundCertificate contain private cryptographic keys?

No. Inbound certificates store only the public certificate, never private keys.

Where is InboundCertificate stored in an SFDX repo?

It is stored in force-app/main/default/inboundCertificates/ with the .inboundCertificate-meta.xml suffix.

How is InboundCertificate utilized in mutual TLS (mTLS)?

Salesforce validates the client certificate presented by external callers against uploaded inbound certificates.