Our end users receive a warning message on their browsers indicating that our Desktop SSO server certificate is untrusted.

• Desktop SSO 
• SSL Certificates
• Okta Classic Engine

• The Desktop SSO server is using a self-signed certificate.
• The name specified in the certificate's Common Name or SAN field does not match the value entered in the IWA redirect URL field on the On-Prem Desktop SSO configuration page in the Okta Admin Console.

NOTE: This guide assumes general familiarity with IIS and creating SSL Certificates via a Certificate Authority (CA) on the domain, or via a third-party CA such as DigiCert or GoDaddy. Please refer to the Configure SSL section of
Install and configure the Okta IWA Web App for Desktop SSO​ for general guidelines on how to create a certificate and configure IIS for use with Desktop SSO.

1. When creating the certificate, the convention (hostname vs FQDN) used in the certificate's Common Name field must match what is used in the IWA redirect URL field in the Okta Admin Console's On Prem Desktop SSO configuration page, AND in the Host Name field in the HTTPS binding in IIS (if specified).

   • To view the IWA Redirect URL currently configured in the Okta Admin Console, navigate to Security > Delegated Authentication and scroll to the IWA Agents section.  The IWA Redirect URL will be displayed as shown below:

     

2. To view the Common Name of an existing certificate, double-click the certificate in IIS or the Certificate MMC Snap-In. The Common Name is displayed as the Issued to address field of the General tab:

• In the above example, the certificate is issued using a hostname (IWASever) instead of an FQDN (for example, IWAserver.company.com). This would result in the following:

  • The IWA redirect URL in Okta should read https://IWAServer/IWA/.  Do not enter an FQDN such as https://IWAServer.company.com/IWA/.
  • The Host Name of the HTTPS site binding in IIS on the Desktop SSO server must either be blank (recommended if the Desktop SSO server is not using IIS to host any other websites) or read IWAServer and NOT IWAServer.company.com.

• If planning to use multiple Desktop SSO servers for failover purposes, it is possible to create a wildcard certificate that can be used on each server within the same domain.

  • When entering the server's FQDN in the Common Name, replace the server's hostname with * (for example, *.company.com).
  • If using a wildcard, use the server's FQDN in the IWA redirect URL field in Okta.

• If using the FQDN instead of the hostname, the server's URL must be added to the client's Local Intranet Zone to prevent an authorization prompt from appearing.

  • A group policy can be created to add the URL to all domain-connected Windows systems, as detailed in the From the MVPs: Setting Internet Explorer Trusted Site Settings via Group Policy Object in Windows Server 2012 R2 Microsoft blog.
  • If planning to use multiple Desktop SSO servers, a single wildcard entry can be added to the zone for simplicity (for example, https://*.<companyname>.com).