Enterprise Application Access (EAA) can use certificates to validate the communication between applications hosted on EAA servers and your users (clients). Certificates provide authentication between the client and server to securely send data with use of Transport Layer Security (TLS).

A server certificate is required for TLS communications between a user's browser and each application exposed through Enterprise Application Access. Enterprise Application Access can generate a self-signed server certificate or you can upload a certificate from an authorized certificate authority (CA).

Optionally you can enable mutually authenticated TLS connectivity between the user's device and Enterprise Application Access when you install certificates on user devices and a CA certificate for user authentication in Enterprise Application Access. For more information see Certificate-based authentication in the IdP, User-facing authentication mechanism for applications, and Configure the user-facing authentication mechanism.

Certificate-based device authentication or user validation in the application

Use certificate-based authentication or user validation in applications. When any user sends a request to access a web application or connects to an identity provider (IdP) login portal, the web browser sends an HTTP header called the user agent. The user agent string contains information about the user's web browser name, operating system, device type and other information. These device parameters are used for certificate-based device authentication or user validation. The user agent provides a valid certificate to authenticate the user's device to the IdP.

In some authentication scenarios a user agent is not capable of following authentication redirects to the login service. To work around this limitation of the user agent, you can configure the EAA service to disable authentication or use an authentication scheme that works well for the user agent. For example, if the user-agent supports Basic, you can configure the user-facing authentication mechanism for applications as Basic. In these scenarios enable certificate-based device authentication or certificate-based user authentication on the application, for additional security.

The certificate-based device authentication inherits certificate validation configuration such as the root certificate authority (CA) bundle and online certificate status protocol (OCSP) provider configuration from the identity provider (IdP) to which the application was assigned. After the application is assigned to an IdP with device certificate authentication enabled, you must explicitly enable certificate validation on the application, if device certificate authentication is also desired for application connections.

While you can use device certificate authentication on applications in conjunction with other user-facing authentication mechanisms, none, form, or basic, the Enterprise Application Access (EAA) service also supports a certificate only certificate-based user authentication for the application access. When the user-facing authentication is configured as certificate only, the identity obtained from the validated client certificate is used as the user identity for access to application.

Certificate-based validation of origin servers

Validate with a certificate for directory server and application server (for HTTPS, RDP and SSH applications). As a leader in Zero-Trust security, Enterprise Application Access doesn't trust anyone or any device. As directories and applications migrate from your data center to public clouds, the EAA connector does certificate validation of the origin servers, using industry standard - TLS technology, mitigating any man-in-the-middle (MITM) attacks. The origin server can be a directory service like AD, LDAP, AD LDS, an application server for an HTTPS web application, an application server for a RDP application, or an application server for a SSH application.

Enterprise Application Access customers can also leverage this enhanced security while communicating with the origin servers which may continue to reside within your data center. The EAA connector inside the data center validates the authenticity of the origin server and improves the security posture.

certificate-based validation

👍
Certificate based origin server validation is optional and can be disabled.

The workflow for enabling origin server certificate validation depends on the type of service:

Directory origin server validation:
1. Upload the ROOT CA certificate with the full bundle for any of the directories like AD, LDAP, AD LDS into EAA.
2. Enable server certificate verification and select this certificate to do origin server validation while configuring your directoryand save the directory. Also see Directory server certificate validation rules and use cases for configuring Host and Host Aliases fields.
  This enables the connector to validate the directory before doing any services like adding authenticated users to the directory, updating groups in directories.
HTTPS origin server validation:
1. Upload the ROOT CA certificate with the full bundle for the web application server into EAA.
2. Enable server certificate verification and select this certificate to do origin server validation while configuring your HTTPS application and deploy it. Note that if you enable server certificate verification and do not select any root CA certificate, the public CA certificates available in the connector are used to validate the origin server. If the origin server is not signed by the public CA, server certificate validation fails. Users are not able to access the web application securely.
  This enables the connector to validate the HTTPS origin server using SSL protocol. Then, users can access the HTTPS access application.

📘
Origin server certification validation is not done for HTTP applications.

RDP origin server validation:
1. Upload the ROOT CA certificate with the full bundle for the RDP server into EAA.
2. Enable server certificate verification and select this certificate to do origin server validation while configuring your RDP application and deploy it. Note that if you enable server certificate verification and do not select any root CA certificate, the public CA certificates available in the connector are used to validate the origin server. If the origin server is not signed by the public CA, server certificate validation fails. Users are not able to access the RDP application securely.
  This enables the connector to validate the RDP origin server with SSL protocol. Then, the user can access the RDP application.
SSH origin server validation:

Add the SSH host key while configuring your SSH application and deploy it.
This enables the connector to validate the SSH origin server with SSL protocol. Then the user can access the SSH application. If no SSH host key is added while configuring the SSH application, then SSH server validation is not done.

📘
Origin server validation is not done for VNC applications, SaaS applications and client-access applications.

Add, edit, and delete certificates

To authenticate an application with a non-Akamai certificate, you first need to add the certificate to Enterprise Application Access (EAA).

You can add a certificate with any one of these methods:

Manually. Paste the contents of the certificate into a specific field, provide the private key, and if applicable, a password for the certificate. Make sure that the certificate is in .pem format.
File Upload. Upload the .crt file and if applicable, provide the password for the certificate.
Certificate Authority (CA). Upload the .crt file from the certificate authority.

If you choose to upload a certificate and you have multiple certificates that you want to upload, you can upload a certificate file that contains more than one certificate.

Log in to EAA Management Portal.
In the EAA Management Portal navigation menu, select System > Certificates.
1. Click Add Certificate.
2. In Name type a unique name for the certificate.
3. In Add Certificate section, select one of the options.
If you selected to manually add a certificate:
1. If a password was configured for the private key, in Password, enter a password.
2. In Cert, paste the contents of the certificate.
3. In Private Key, paste the private key associated with the certificate.
If you selected to upload a certificate with File Upload:
1. If a password was configured for the certificate, in Password, enter a password.
2. Click Choose File to locate and select the certificate file.
If you selected the Certificate Authority (CA) option, click Choose File to locate and select the certificate file.
Click Save changes.
1. Click Save.
  A new entry should be created for the certificate you just uploaded with the Name, CN, Created, and Expires values populated. There are no applications associated with the certificate, since it was just uploaded.
If you selected Custom Certificates option:
1. Click Add New Certificate
2. In Name type a unique name for the certificate.
3. If a password was configured for the private key, in Password, enter a password.
4. For Cert, if you selected Manual option, paste the certificate body and the associated private key.
To edit a certificate, click the pencil icon next to the certificate and make your edits and save it.

📘
Self-signed certificates cannot be edited.
To delete a certificate, click the trash icon next to the certificate.

Next, to use the certificate for an external domain, see Associate a certificate for using your own domain for your application.

Upload a ROOT CA certificate for origin server validation

If you want the EAA connector to do validation of the origin server for your directory service, web server hosting HTTPS applications, RDP server hosting the RDP application, you need to upload a root CA certificate with the full bundle of all the subordinates. All communication between the Enterprise Application Access connector and the origin server is done with TLS protocol, preventing man-in-the-middle (MITM) attacks.

Log in to EAA Management Portal.
In the EAA Management Portal navigation menu, select System > Certificates.
Click Add Certificate.
In Name type a unique name for the certificate.
In Add Certificate select Certificate Authority (CA).
Do not use Manually or Via file upload options for adding ROOT CA certificate.
Click Choose File to locate and select the ROOT CA certificate file with the full bundle.
Click Save changes.

To assign the certificate to the directory origin server see Add or edit an LDAP, AD or AD LDS directory.
To assign the certificate to the web application (HTTPS) origin server see Configure access parameters for an application.
To assignin the certificate to the RDP origin server see Configure and deploy a remote desktop application.

Associate a certificate for using your own domain for your application

Associate a self-signed certificate or uploaded certificate to an application when you use your own external domain.

When you use your own domain for your application and a certificate that matches the domain is associated with the application, users are able to securely communicate to the EAA Cloud:

If you use an Akamai domain, you do not need to provide a certificate.
If you use your own domain, you can have Akamai generate a certificate for you or you can select to use an uploaded certificate from an authorized certificate authority (CA). It is recommended to provide your own certificate.

📘
14 days before the certificates expire, the applications change to Deployment Not Ready state. You should renew the certificate before expiry and redeploy the application, although the application would work fine during the expiration warning period.

📘
In some cases, you may need to provide an intermediate certificate from your domain provider. When you paste your standard certificate in Cert, paste the intermediate certificate just below it.

Log in to EAA Management Portal.
In the EAA Management Portal navigation menu, select Applications.
Select your application to open it.
In External host name select your domain.
To use a self-signed certificate generated by Enterprise Application Access:
1. In External Domain Certificate, select Use self-signed certificate.
2. Click Generate self-signed certificate.
  A message about application using a self-signed certificate appears.
To use an uploaded certificate:
1. Select Use uploaded certificates.
2. Select a certificate.
Click Save.