Certificate-based authentication

On the Settings tab, you can configure STA to allow certificate-based authentication (CBA) as an authentication method in your deployment.

To enable certificate-based authentication, you need to add at least one certificate chain from an issuing certificate authority (CA) to your trust store in STA. The trust store lists the certificate chains from the CAs that your organization trusts for the authentication of your users. Adding an issuing CA establishes a trust relationship that the system relies on to verify the authenticity of your users when they authenticate through STA.

After you configure certificate-based authentication, you can use it as an authentication requirement in your access policies and scenarios. When a user accesses an application that is controlled by STA, and the access request is governed by a policy that requires CBA, then the user must provide their certificate, such as a smart card.

Supported certificate types

In STA, certificate-based authentication supports all certificate container formats, such as smart cards, USB dongles, and soft certificates. However, the certificates must meet the following conditions:

• The certificates are configured for client authentication (ISO OID code 1.3.6.1.5.5.7.3.2).

• For Chrome, Internet Explorer, and Microsoft Edge browsers on Windows, certificate containers are managed by Microsoft Cryptographic Application Programming Interface (MS-CAPI) middleware.

• For Firefox browsers, certificate containers are managed by PKCS#11 middleware.

• For Safari browsers on macOS, certificates are configurable in the Keychain Access app.

There are usability limitations on Firefox and Safari browsers due to the browser’s implementation of TLS authentication and the associated certificate handling. For example, on these browsers, the user may not be prompted to insert their smart card.

Configure browser settings for your users

For users who use the following browsers, authentication with certificate-based authentication requires preliminary configuration steps:

Configure Internet Explorer for Certificate-Based Authentication

1. In Internet Explorer, on the Tools menu, select Internet options.

2. On the Internet Options dialog box, select the Security tab, select the Trusted Sites zone, and then select Sites.

   

3. On the Trusted Sites dialog box, enter the URL for the IDP, select Add, and then select Close.

   The URL varies based on your service zone.

4. On the Internet Options dialog box, select Custom level.

   

5. On the Security Settings - Trusted Sites Zone dialog box, under the Access data sources across domains option, select Enable and then click OK.

6. On the Internet Options dialog box, click OK.

Configure Firefox for Certificate-Based Authentication

If CBA works with Edge and Chrome, but fails in Firefox with a TLS error in the STA access logs, your smart card is probably not compatible with the Firefox OS Cert Module.

Firefox version 75 or greater is preloaded with an OS Cert Module that can load certificates from the OS cert store. If you load an additional PKCS#11 module, Firefox prefers the preloaded Firefox OS Cert Module. To use a different module, you need to unload the Firefox module before you load another PKCS#11 module.

To load a compatible PKCS#11 module, follow the instructions from your smart card vendor and complete the following steps:

1. In Firefox, open the menu and select Settings.

2. Select Privacy & Security.

3. Scroll down to the Certificates section and select the Security Devices button.

4. On the Device Manager, select the OS Client Cert Module, select Unload, and then select OK to confirm the deletion.

   

5. Select Load.

6. On the load PKCS#11 Device Driver dialog box, enter the Module Name, select the Module filename, and then click OK.

   

7. Click OK to close the Device Manager.

Configure Safari for Certificate-Based Authentication

1. Insert your smart card.

2. Open Keychain Access, right-click the valid certificate, and select New Identity Preference.

3. Enter the URL for which a certificate is required, and then select Add.

   There is an URL for each service zone:

   • For the EU service zone, the URL is: *.pki.eu.safenetid.com

   • For the class zone, the URL is: *.pki.safenetid.com

   The new entry is added in login > All Items.

   If you want to use another smart card, you need to add a new identity preference, which replaces the previous identity preference.

Add an issuing CA to the STA trust store

On the STA Access Management console Settings tab, you can configure STA to allow certificate-based authentication (CBA) as an authentication method in your deployment.

STA certificate-based authentication is not supported on iOS and Android platforms.

Before you can use CBA in your policies, you must add at least one issuing CA to the STA trust store.

STA trust store with issuing CAs

The system uses the issuing CA to validate the user certificates at the time of authentication. In the STA trust store, the issuing CA is represented by a certificate chain that includes its parent CA hierarchy up to the root CA.

The trust store is like a white list. It lists the issuing CAs that your organization trusts for the authentication of your users. Each issuing CA includes a validity period.

The certificate chain must be in a PKCS#7 package (*.p7b file) that contains the full issuing CA certificate chain. A P7B file contains the trust chain without the private key. It includes only certificates and chain certificates (intermediate CAs).

After you add an issuing CA, the certificate-based authentication becomes available to use in your application policies.

1. On the STA Access Management console, select the Settings tab.

2. Under Authentication, select Certificate-Based Authentication.

3. Select Add Issuing CA.

   

4. On the Add Issuing CA dialog box, upload the *.p7b file that contains the full issuing CA certificate chain.

   

   The Issuing CA Information is displayed and the User Certificate Validation displays the default settings.

   

5. Under Issuing CA Information, in the Name field, enter a unique name that identifies the issuing CA.

   The name is displayed in the Trust Store on the Certificate-Based Authentication screen.

   The Certificate Validity Period displays the shortest validity period in the chain (at the end of the chain). The root CA has the longest validity period. STA checks the certificate validity period against the current time to determine whether it's valid.

   The Certificate Path displays the path from the root of the hierarchy to the lowest certificate in the chain. The lowest certificate in the chain represents the issuing CA that issues the user certificates.

6. Under User Certificate Validation, select a Revocation Check option.

   The revocation check is based on checking the certificate revocation list (CRL) that is referenced by the CRL distribution point in the user certificate. To execute the revocation check, STA extracts the CRL from the CRL distribution point that is indicated in the user certificate. This distribution point must be accessible by STA through the public internet. STA supports both HTTP and HTTPS endpoints for downloading the CRL lists.

   The revocation check determines whether the CA has revoked the user's certificate before the scheduled expiration date. A CA can revoke a certificate when it determines that the certificate should no longer be trusted.

   The following are the revocation check options:

   • Reject certificate when revocation status cannot be checked: (Default) This is the recommended and most secure option.

   • Accept certificate when revocation status cannot be checked: Select this option if the need to ensure access outweighs the risk of accepting revoked certificates. For example, a network issue might have prevented the system to extract the certificate revocation list.

   • Do no check revocation status: Select this option if your system manages compromised certificates in a different way, or if you want to turn of revocation checking during implementation or testing.

7. Under User Mapping, select the Certificate Attribute that you want to compare with a User Attribute in STA:

   The certificate attributes are retrieved from the certificate structure:

   • UPN: The User Principal Name (UPN) is retrieved from Subject Alternative Name: Other Name: Principal Name.

   • Email address: The email address is retrieved from Subject: E.

   • Common name: The common name is retrieved from Subject: CN.

   • RFC822 name: The RFC822 name is retrieved from Subject Alternative Name: RFC822 Name.

   • Serial number: The serial number is retrieved from Subject: SERIALNUMBER.

     

     If you select Serial Number, STA extracts the user identity information from the Subject : SERIALNUMBER field of the certificate and compares it to the STA user attribute that is configured for the same issuing CA.

     

8. For user mapping, if you need STA to consider only what is before the @ symbol, select Strip the domain name from the selected certificate attribute.

   For example, selecting this option strips @domain.com from myname@domain.com, which leaves myname for the user mapping.

9. Select the User Attribute in STA that you want to compare with the selected certificate attribute.

10. Click Save.

    The certificate-based authentication option is now available to use as an authentication requirement in your policies.

Update an issuing CA

You can update the name, revocation check option, and user mapping attributes.

If an issuing CA certificate has already expired, you cannot update it and can only delete it.

1. On the STA Access Management console, select the Settings tab, and then select Certificate-Based Authentication.

   The Trust Store lists the issuing CAs that are configured for the virtual server.

   

2. In the row for the issuing CA, select the menu, and then select Edit.

   The Issuing CA Information and User Certificate Validation information is displayed.

   

3. Update the information as required, and then select Save.

Delete an issuing CA from the STA trust store

You can delete an issuing CA to remove it from the trust store. For example, you might want to delete an issuing CA when the certificate validity period has expired.

If any policies require CBA for authentication, the system prevents you from deleting the last valid issuing CA.

1. On the STA Access Management console, select the Settings tab, and then select Certificate-Based Authentication.

   The Trust Store lists the issuing CAs that are configured for the virtual server.

   

2. In the row for the issuing CA, select the menu, and then select Delete.

3. On the confirmation message, select Delete.

Set up a quick test environment using a self-signed certificate

For demonstrations, here’s an easy way to generate a certificate for client authentication and smartcard logon for use when demonstrating STA.

1. Open PowerShell and run this command to generate a certificate with client authentication and smartcard logon:

   New-SelfSignedCertificate -Type Custom -Subject "0.9.2342.19200300.100.1.1=jonas,E=jonas@swedemo.se,CN=Jonas Swed,O=swedemo.se" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.4.1.311.20.2.2","2.5.29.17={text}upn=jonas@swedemo.se") -KeyUsage DigitalSignature -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
   

2. Export the certificate from the Windows Personal store (MMC) to your authenticator of choice.

3. Export the chain and upload to STA Access Management console > Settings.