Cloud Authentication Service Certificates

Document created by RSA Information Design and Development on Apr 20, 2018Last modified by RSA Information Design and Development on Jun 15, 2018
Version 6Show Document
  • View in full screen mode

A Cloud Authentication Service deployment can require the following certificates:

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 Certificate from LDAP Directory Server

You need an SSL certificate from your LDAP directory server if you want to use an encrypted connection (LDAPS) to your directory server. RSA strongly recommends that you enable SSL 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 certificate or the SSL 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 an Identity Source for the Cloud Authentication Service.

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

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

Certificate Bundle for RSA SecurID Access Application Portal or RSA Authentication Manager Integration

You need a private key, public certificate, and certificate chain to secure communications for the following:

  • The RSA SecurID Access Application Portal as part of an SSO Agent deployment.
  • You want Cloud Authentication Service users to access resources protected by RSA SecurID.

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.

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

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 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 RSA SecurID Access 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 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.

Certificates for SSO Agent SAML Applications

If you add an 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 SSO Agent.

RSA SecurID Access 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 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

 

 

You are here
Table of Contents > Certificates > Cloud Authentication Service Certificates

Attachments

    Outcomes