Cloud Authentication Service Certificates

A Cloud Authentication Service deployment can require the following certificates:

Any certificate and keys you upload to the Cloud Administration Console for SSO SAML applications, SecurID Application Portal (domain certificate), identity source, identity provider and so on must each have a minimum key length of 2048 bits.

You only need to manage certificates for the components that you are using. See each section below to understand what is required for your deployment.

In a production environment, use a well-known CA for certificates. In a test environment, you might use a self-signed certificate or a certificate signed by an internal CA trusted by their domain members.

SSL/TLS Certificate from LDAP Directory Server

You need an SSL/TLS certificate from your LDAP directory server if you want to use an encrypted connection (LDAPS) to your directory server. SecurID strongly recommends that you enable SSL/TLS encryption to secure communication between an identity source and the identity routers.

When you add the identity source in the Cloud Administration Console, you upload the Certificate Authority (CA) root certificate for each directory server's SSL/TLS certificate or the SSL/TLS certificate itself if it is self-signed. The Cloud Authentication Service supports the X509 certificate file format.

For various ways that you can get this certificate, see 2 ways to put the S in LDAPS. For instructions on adding an identity source, see Add, Delete, and Test the Connection for an Identity Source in the Cloud Authentication Service.

If you modify an SSL/TLS-enabled identity source, you must do the following:

  • If you switch between enabling or disabling SSL/TLS encryption, you must change the directory server port.
  • If you change to a different directory server, you must replace the existing SSL/TLS certificate.

Certificate Bundle for SecurID Application Portal or RSA Authentication Manager Integration

You need a private key, public certificate, and certificate chain to secure communications in either of the following situations:

  • You have an SSO Agent deployment that includes the SecurID Application Portal.

  • Your Cloud Authentication Service deployment is integrated with Authentication Manager 8.4 Patch 3 or earlier and users will use Authenticate OTPs to access resources protected by SecurID.

    Note: When the Authentication Manager administrator configures the cloud integration, this certificate chain (root certificate plus optional Certificate Authority certificates) is identified in the Operations Console as the identity router root certificate.

You add the private key, public certificate, and certificate chain in the Company Settings page in the Cloud Administration Console. For instructions, see Configure Company Information and Certificates.

Private Key

Generate the private key using your own infrastructure or instructions provided by your CA. The private key must meet the following requirements:

  • RSA format
  • 2048 bit or greater
  • Not password protected
  • Matches the public certificate

Public Certificate and Certificate Chain

The public certificate is issued from the certificate authority (CA) for your domain. The Certificate Chain is provided by the CA and is valid for your public certificate. If necessary, submit a certificate signing request (CSR) to a trusted Certificate Authority (CA) to obtain the public certificate and certificate chain. The specific instructions vary by CA.

When submitting the CSR, consider the following:

  • The certificate and certificate chain files are in x509 PEM format. If you are prompted for a certificate format based on web server type, choose Apache.

  • Usually requesting a "SSL or TLS server certificate" is enough information for the CA administrators to choose the correct certificate profile or template. If the CA used does not have any SSL or TLS server profile or template, the following extensions are recommended:

    • KeyUsage: keyEncipherment, keyAgreement, digitalSignature

    • ExtendedKeyUsage: Protected domain name

    • SubjectAlternativeName: DNS name of the protected domain name

    • The CA might include other extensions such as SubjectKeyIdentifier and AuthorityKeyIdentifier.

  • The common name uses the protected domain name, such as *.portal.example.com.The IDR SSO Agent uses cookies based on the PDN (for example, *.sso.example.com), so that users can use SSO between applications.

    For SAML-based applications, all user traffic goes to the portal hostname (for example, https://portal.sso.example.com/...). For HTTP-Federation (HFED) or Trusted Headers applications, the identity router uses a unique proxied hostname within the protected domain name (PDN) for each application webserver hostname (for example, https://www-appname-com.sso.example.com/... and https://another-app.sso.example.com).

    To allow for flexibility with all application types, consider obtaining a wildcard certificate valid for the PDN. With a wildcard certificate and wildcard DNS CNAME you can quickly add more applications to SecurID without updating the certificate (with new subject alternative names) or modifying DNS entries (adding CNAMEs).

    However, if you are unable to use wildcard certificates per company policy or for other reasons, or if you use only SAML-based integrations, you can use a certificate that is valid only for the IDR SSO Agent portal hostname.

Certificates for Protected Resources

Depending on your company policy, you might need to add certificates for resources that you are protecting with the Cloud Authentication Service.

Certificates for Relying Party SAML Applications

If you are add a relying party SAML application, you can use public key certificates and private keys to help secure transactions carried out between the SP (the SAML application) and the IdP (Cloud Authentication Service). You use the Cloud Administration Console to manage certificates between the IdP and SP. For instructions, see Add a Service Provider.

The SP can sign the SAML requests that it sends to the IdP, but the signature is not required. If the SP signs the requests, when you configure the SP in the Cloud Administration Console, you upload the certificate that the IdP uses to validate the request signature. The SP certificate does not need to be signed by a Certificate Authority.

The SAML IdP for the Cloud Authentication Service has its own certificate and always signs the SAML assertions. The IdP uses the same private key and certificate for all SPs. You can download the IdP certificate to validate the signature when you configure the SP or when you view the metadata. You cannot download the private key.

The following algorithms are supported for SAML applications in the SecurID Application Portal.

Supported Algorithm
Signature Algorithm

rsa-sha256

rsa-sha384

rsa-sha512

dsa-sha256
Digest Algorithm

sha1

sha256

sha384

sha512

Certificates for IDR SSO Agent SAML Applications

If you add an IDR SSO Agent SAML application, you can use public key certificates and private keys to help secure transactions carried out between the SP (the SAML application) and the IdP (Cloud Authentication Service). You use the Cloud Administration Console and the application's administration console to manage certificates between the IdP and SP. For instructions, see Add a SAML Application.

The SP has a private key to sign requests and the IdP has the corresponding certificate to validate the signed requests. The IdP has a private key to sign assertions and the SP has a corresponding certificate to validate the signed assertions.

You can use your own public key infrastructure to issue keys and certificates, or you can upload existing ones. If certificates are not available, you can use the Cloud Administration Console to generate a certificate and private key for the connection you are creating. For more information, see Generate and Download a Certificate Bundle for Service Providers and Identity Providers for the IDR SSO Agent.

SecurID requires x509 v3 (PEM) format certificates.

If you request a certificate from a CA, consider the following:

  • Your company policy's might dictate that a CA issues your signing or encryption certificate.
  • The certificates must be in x509 v3 (PEM) format.

  • Usually requesting a "signature certificate" is enough information for the CA administrators to choose the correct certificate profile or template. If the CA used does not have any signature certificate profiles/templates, the following extensions are recommended:

    • KeyUsage: digitalSignature

    • The CA might include other extensions such as SubjectKeyIdentifier and AuthorityKeyIdentifier.

  • Usually requesting a "encryption certificate" is enough information for the CA administrators to choose the correct certificate profile or template. If the CA used doesn't have any encryption certificate profiles/templates, following extensions are recommended:

    • KeyUsage: keyEncipherment, keyAgreement, dataEncipherment

    • The CA might include other extensions such as SubjectKeyIdentifier and AuthorityKeyIdentifier.

Trusted Certificate Authorities for HFED or Trusted Headers Applications

If you add an HTTP Federation Proxy (HFED) or trusted headers application in an IDR SSO Agent deployment, the identity routers connect directly to the application web servers. If SSL is enabled for these applications, the application web server must have a valid certificate signed by a certificate authority (CA) that the identity routers trust.

The identity routers automatically trust valid certificates signed by:

However, some companies use an internal or lesser-known CA to sign certificates used for their application web servers. To establish trust between the identity router and an internal CA, you can upload one or more CA certificates using the Cloud Administration Console. For instructions, see Upload Certificates for Trusted Certificate Authorities.

The identity routers require that an SSL certificate is valid. Valid SSL certificates contain:

  • A signature from a trusted CA
  • A name that matches the web server's hostname
  • An expiration date that has not passed