We’re excited to announce multiple certificate support for SSL inbound inspection in Oracle Cloud Infrastructure (OCI) Network Firewall in supported commercial regions. This capability enables customers to configure SSL inbound inspection across multiple certificate-backed applications, domains, and environments through a more flexible decryption policy model.
Modern application ingress rarely maps cleanly to a single hostname, certificate, or deployment environment. A shared ingress architecture may support multiple public applications, subdomains, production and non-production environments, SaaS-style customer-specific endpoints, or business units with separate certificate lifecycles.
OCI Network Firewall provides capabilities including stateful access control, URL filtering, SSL inspection, and intrusion prevention. Multiple certificate support for SSL inbound inspection builds on these capabilities by allowing a single SSL inbound inspection decryption rule to reference multiple certificates. This helps customers maintain centralized inspection and can help reduce duplicated policies, separate firewall deployments, and tightly coordinated certificate rotation workflows.
What is Multiple Certificate Support for SSL Inbound Inspection?
Multiple certificate support for SSL inbound inspection allows customers to associate more than one certificate with an SSL inbound inspection decryption rule in OCI Network Firewall. While a certificate with multiple subject alternative names (SANs) can cover several hostnames in some deployments, it does not fit every environment. Different applications, tenants, business units, or environments may require separate certificate ownership, rotation schedules, private keys, or operational controls.
With this enhancement, a single SSL inbound inspection decryption rule can reference multiple mapped secrets. Each mapped secret still contains one certificate and private key pair, so the mapped secret resource does not change. The change is at the decryption rule level.
During SSL/TLS handshake processing, OCI Network Firewall evaluates the certificates associated with the matched decryption rule and selects the certificate that matches the certificate presented by the protected backend server. Certificate order within the rule does not determine selection.
This is different from creating multiple decryption rules with similar match criteria but different certificates. Once a decryption rule is selected, the firewall evaluates only the certificates associated with that rule. It does not continue searching later matching rules for another certificate. Multiple certificate support addresses this by keeping the relevant certificate set on the matched decryption rule.
Multiple certificate support extends certificate references for SSL inbound inspection, but it does not change the rest of the inspection model. Customers still need to validate certificate chains, confirm that the private key matches the certificate, maintain correct routing and traffic symmetry, and verify that traffic matches the intended decryption rule.
The feature is generally available for SSL inbound inspection use cases and can be configured through the OCI Console, API, CLI, SDKs, and Terraform. Customers should consult the official OCI Network Firewall documentation for configuration steps, prerequisites, regional availability, and supported limits.
Why this matters
As application ingress patterns grow more distributed, certificate management can make consistent encrypted-traffic inspection more complex. When a decryption rule supports only one certificate, customers may need to duplicate policies, deploy separate firewall paths, or tightly coordinate certificate updates across network security and application teams.
Multiple certificate support can help customers maintain a centralized inspection model and reduce the need for certificate-driven rule or architecture duplication. Security teams can use a shared OCI Network Firewall inspection point for applications with different certificates. This approach may reduce the need for duplicated architecture and help align policy with certificate ownership, application lifecycles, and rotation workflows.
Customer use cases and scenarios
Multiple certificate support for SSL inbound inspection can be useful when customers need encrypted inbound inspection across more than one certificate-backed endpoint.
Common use cases include hosting multiple public applications behind OCI Network Firewall, inspecting traffic for multiple domains or subdomains, supporting separate certificates for production and non-production environments, applying inbound inspection to SaaS-style or multi-tenant applications, consolidating inspection policies across business units, and migrating from on-premises architectures that already rely on multiple certificate mappings.
Scenario 1: Certificate rotation without tightly coupled firewall and server changes
A platform team manages app.example.com, whose certificate expires in 30 days. The network security team owns OCI Network Firewall policy, while the application team owns the backend server certificate. Their change windows do not align.
The following diagram illustrates the certificate rotation workflow.
With multiple certificate support, the network security team first adds a mapped secret for the replacement certificate to the existing SSL inbound inspection decryption rule. The rule now references both the current and replacement certificates. During the overlap period, the backend server continues to present the current certificate, allowing the firewall to continue inspection using the corresponding configured certificate.
Later, the application team updates the backend server to present the replacement certificate. Existing sessions are handled according to the documented session and policy-update behavior, while new inbound sessions can use the newly added certificate when the backend server presents the matching certificate. In this scenario, the server-side rotation may not require another firewall-policy update, provided the replacement certificate was added and validated in advance.
After validation, the network security team removes the old certificate reference from the rule as part of normal certificate cleanup.
Scenario 2: Multi-domain financial services applications
A financial services company runs several public services in OCI, such as payments.example.com, api.example.com, and customer.example.com.
Each service has its own certificate because each application has a different lifecycle, owner, and operational risk profile. The security team wants applicable inbound traffic inspected through OCI Network Firewall before it reaches the application tier.
With multiple certificate support, the team can configure SSL inbound inspection with the relevant certificates for these endpoints instead of building separate firewall paths for each application. This can help keep inspection centralized while still respecting certificate separation across services.
Scenario 3: SaaS provider with customer-specific hostnames
A SaaS provider hosts customer-facing application endpoints such as customer-a.saas.example.com, customer-b.saas.example.com, and customer-c.saas.example.com.
Some deployments use dedicated or customer-provided certificates, and certificate rotation schedules may vary by tenant. The provider still wants consistent inbound inspection policy across the shared application platform.
By associating multiple certificates with the inbound inspection configuration, the provider can inspect traffic across multiple certificate-backed hostnames and may reduce the need for policy duplication or separate firewall deployments created solely to accommodate different certificates.
Scenario 4: Production and non-production inspection consistency
An enterprise platform team operates production and non-production services behind shared network security controls. Production certificates are managed separately from staging and development certificates, but the security team wants consistent inbound inspection behavior across environments.
Multiple certificate support allows the team to configure inspection for each relevant certificate-backed endpoint while using a consistent policy approach. The team can validate behavior in a controlled environment, coordinate with application owners, and then roll out inspection according to the organization’s change-management process.
Across these scenarios, the common value is a more flexible certificate-aware inspection model: customers can keep inspection centralized while allowing certificates to follow real application, tenant, and environment boundaries.
Benefits
Multiple certificate support for SSL inbound inspection provides a more flexible way to apply SSL inbound inspection to encrypted traffic as application portfolios grow.
Key benefits include:
- Support more flexible certificate rotation: Customers can stage overlapping certificates on the firewall before rotating the certificate on the backend server or application endpoint.
- Support inspection consolidation: Customers that previously used separate firewall paths only to handle different certificates can evaluate whether multiple certificate support allows a more streamlined, centralized inspection design.
- Inspect encrypted inbound traffic across more applications: Customers can extend SSL inbound inspection to multiple domains, applications, or certificate-backed endpoints without requiring all supported endpoints to use a single certificate model.
- Centralize firewall inspection for multiple domains: Security teams can use OCI Network Firewall as a shared inspection point while still supporting separate certificates for different services.
- Reduce architectural workarounds: Customers may be able to reduce rule duplication, policy cloning, or separate firewall deployments that exist only to work around certificate constraints.
- Support certificate and policy management: Multiple certificate references can make it easier to align decryption policy with real certificate ownership, rotation, and application lifecycle patterns.
Operational behavior and best practices
Multiple certificate support for SSL inbound inspection preserves the existing mapped secret model while extending how decryption rules reference certificates.
Configuration behavior
A mapped secret continues to contain one certificate and private key pair. The enhancement is that a single SSL inbound inspection decryption rule can reference multiple mapped secrets.
The existing single-secret behavior remains supported. For a given rule, customers should configure either the single mapped secret option or the multiple mapped secrets option, not both at the same time. The multiple-certificate model uses a list of mapped secret references.
OCI Network Firewall supports multiple certificate references on an SSL inbound inspection decryption rule, subject to documented service limits.
When a policy is updated to add a new certificate, existing sessions are handled according to the documented session and policy-update behavior. New sessions can use the new certificate when the backend server presents the matching certificate.
Certificate rotation
For certificate rotation, consider using an overlap period during which both the current certificate and the replacement certificate are valid. Add the replacement certificate to the SSL inbound inspection decryption rule before the backend server begins presenting it.
This approach can allow the network security team to prepare the firewall policy in advance, while the application team performs the server-side certificate rotation during its own change window.
After the backend server starts presenting the replacement certificate, validate that new sessions are inspected as expected. Confirm the server is using the new certificate, review available firewall logs, and test the relevant traffic paths for each certificate-backed endpoint.
Certificate cleanup
Multiple certificate support helps with rotation and multi-application inspection, but it does not remove the need for certificate lifecycle management. Expired or unused certificate references should be removed in accordance with the documentation because they may contribute to configuration-validation or deployment issues. Removing expired or unused certificates also helps keep the rule within supported limits.
Before removing an old certificate, coordinate with application owners and validate that server-side rotation is complete. Decryption rule usage can help confirm that the rule is active, but teams should not assume that per-certificate usage metrics are available unless explicitly documented.
Best practices
To make rollout smoother:
- Use clear certificate naming conventions that identify application, environment, and ownership.
- Validate certificate chains and private key pairing before deployment.
- Use overlapping certificate validity windows for rotation.
- Add replacement certificates to the firewall before backend server rotation.
- Coordinate with application owners before enabling inspection or removing old certificates.
- Test policy behavior in a controlled environment before broad rollout.
- Monitor firewall logs after rollout to confirm expected decryption behavior.
- Remove expired or unused certificates to help reduce the risk of configuration-validation or deployment failures and stay within supported limits.
Closing
Encrypted traffic inspection can be an important component of a broader application-security strategy, but inspection policy needs to keep pace with how applications are deployed: across multiple domains, environments, tenants, and certificate lifecycles.
Multiple certificate support for SSL inbound inspection in OCI Network Firewall can help customers apply inspection across more applications while simplifying some certificate-related operational workflows. It can provide a practical way to centralize inspection, help provide visibility into inspected encrypted traffic, reduce architectural workarounds, and help simplify coordination during certificate rotation for multi-domain and multi-application environments.
To learn more, review the OCI Network Firewall documentation or try configuring multiple certificate support for SSL inbound inspection in your OCI Network Firewall environment.