Versions Compared

Old Version 2

changes.mady.by.user Former user

Saved on

compared with

New Version 3

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This section guides you through securing REST services and how requests to REST APIs are authenticated and authorized in the WSO2 Identity Server.  

...

Configure intermediate certificate validation

Tip

To use this feature, apply the 38633383 WUM update for WSO2 Identity Server 5.65.0 using the WSO2 Update Manager (WUM). To deploy a WUM update into production, you need to have a paid subscription. If you do not have a paid subscription, you can use this feature with the next version of WSO2 Identity Server when it is released. For more information on updating WSO2 Identity Server using WUM, see Getting Started with WUM.

Configuring intermediate certificate validation enables you to restrict certificates that are used during mutualSSL authentication to certificates that are signed by the defined issuers(cert_cns).

To configure intermediate certificate validation, configure the following in the identity.xml file as given below. 

ParameterDescriptionSample Value
IntermediateCertificateValidationDefines whether intermediate certificate validation is enabled or not.true
IntermediateCertsSpecifies the context paths of the intermediate certificates.

Multiple <CertCN> elements can be used for multiple certificates.

localhost
ExemptContext

Specifies the context paths that needs to be excempted from intermediate certificate validation. 
Multiple <Context> elements can be used for multiple contexts.


Example:

Code Block
<IntermediateCertValidation enable="true">
     <IntermediateCerts>
         <CertCN>wso2isintcert</CertCN>
         <CertCN>localhost</CertCN>
     </IntermediateCerts>
     <ExemptContext>
         <Context>scim2</Context>
     </ExemptContext>
 </IntermediateCertValidation>
Info

When using intermediate certificate validation, note that CN will be taken as the username instead of retrieving it from the header therefore, the incoming certificate request CN should ideally be the username of the user who is sending the request.

The certificate CN should be in the following formats for the following cases.

  • If the user is in the primary userstore, the incoming cert CN should be just the <username> e.g., john.
  • If the user is in a secondary userstore, the incoming cert CN should be <userstore_domain>/<username> e.g., SECONDARY/john.
  • If the user is not a super tenant and belongs to the primary userstore, the incoming cert CN should be <username@tenant_doman> e.g., john@abc.com.
  • If the user is not a super tenant and belongs to a secondary userstore, the incoming cert CN should be <userstore_domain>/<username@tenant_doman> e.g., SECONDARY/john@abc.com.