XenMobile Server is capable of being Federal Information Processing Standards (FIPS) 140-2 compliant. When installed in FIPS mode XenMobile Server uses FIPS-certified cryptographic modules provided by OpenSSL to secure all data-at-rest and data-in-transit.
Achieving FIPS compliance with a solution such as XenMobile requires all components to secure all data-at-rest and data-in-transit using FIPS-certified cryptographic modules.
XenMobile environment components such as the XenMobile Server, the MDX container and mobile devices (iOS, Android and Windows) are equipped with these modules. XenMobile environment usually consists of a NetScaler appliance that front-ends all mobile device traffic.
In a FIPS enabled XenMobile environment the NetScaler appliance should be a FIPS edition appliance equipped with a certified FIPS module to secure the data. For more information on XenMobile FIPS 140-2 Compliance visit here.
XenMobile Server uses a SQL database server to store all configuration information. When FIPS mode is enabled, this configuration information (data-at-rest) is encrypted with FIPS-certified cryptographic modules. To achieve FIPS compliance, it is also necessary to secure the data in transit between the XenMobile Server and the database server using Secure Sockets Layer (SSL) protocol. To communicate over SSL the SQL Server must be installed with a FIPS-compliant digital certificate. This SSL certificate can either be a public certificate or a certificate from an internal Certificate Authority (CA) such as a Microsoft Windows based CA.
For XenMobile Server to successfully establish secure SSL communication with a remote SQL Server, the XenMobile Server should have access to the root certificate of the CA that issued the corresponding server certificate installed on the SQL Server. Using this root certificate, XenMobile Server performs the SSL handshake with the SQL Server and validates the server certificate.
The following configuration guidance will assist you with installing XenMobile Server in FIPS mode using a Microsoft SQL Server. Please review XenMobile Server Systems Requirements to get a list of supported SQL Server versions.
- FIPS mode should be enabled only during the initial setup of XenMobile Server and should not be toggled on/off at a later date.
- The Toggle FIPS mode option in the XenMobile command-line interface is not for production use. This option is intended for non-production, diagnostic use and is not supported on a production XenMobile Server.
- If you use a self-signed certificate for SQL Server, you will need a copy of the root CA certificate that issued your self-signed certificate. The root CA certificate must be imported to the XenMobile server during installation. Using a self-signed certificate is not recommended for production deployments. For more information refer to this link.
- In some cases, SQL Server can also be configured with a wildcard certificate, which requires advance registry configurations. Please contact Microsoft to get assistance with configuring a wildcard certificate on the SQL Server. In the following sample configuration, we will use a single domain certificate.
- If you are using a SQL Server named instance configure it to use a static port. For more information refer to this link.
- Port 1433 (the default) or a custom, instance specific, port should be allowed on the firewall from the XenMobile Server.
- For AlwaysOn Availability Groups the certificate must be configured for each server node participating in the failover cluster. The certificate must also be configured with a list of all availability group listeners set in the Subject Alternate Name of the certificate. For more information refer to this link.
- If the SQL Server is running on a failover cluster, the common name must match the host name or FQDN of the virtual server and the certificates must be provisioned on all nodes in the failover cluster. For more information refer to this link.
|Step 1: Create and install an SSL certificate on the SQL Server. Please note that enabling SSL will require all application servers, hosting databases on the specific instance, to use SSL communication. Please consult your SQL Database Administrator before making the following changes.|
|1. Create a Certificate Signing Request (CSR): Any Windows Server running the Microsoft Internet Information Services (IIS) role can be used to perform this task.|
|Open IIS Manager.|
|Navigate to the server name and in Features View, double-click Server Certificates.|
|In the Actions pane, click Create Certificate Request.|
|On the Distinguished Name Properties page of the Request Certificate Wizard, type the following information, and then click Next.
i. The unabbreviated name of the city or locality where your organization or organizational unit is located.
ii. In the State/province text box, type the unabbreviated name of the state or province where your organization or organizational unit is located.
iii. In the Country/region text box, type the name of the country or region where your organization or organizational unit is located.
|On the Cryptographic Service Provider Properties page, select Microsoft RSA SChannel Cryptographic Provider.
In the Bit length drop-down list, select 2048-bit length.
|2. Request a certificate from the Certificate Authority:|
|Open a web and browse to “https://servername/certsrv”, where servername is the name of the Web server hosting the CA Web enrollment pages, and login with administrator credentials.
Click Request a certificate, and then click Advanced certificate request.
|Click Advanced certificate request.||
|Paste to paste the contents of the certificate request created in step 1 into the box.
Select the “Web Server” template and click Submit
|Click Download certificate. Save the file to a location accessible from the IIS server used in step 1.|
|3. Complete the CSR:|
|Open IIS Manager and navigate to the server name.
In Features View, double-click Server Certificates.
|In the Actions pane, click Complete Certificate Request.|
|On the Complete Certificate Request page provide path of the file you saved in step 2.vii above.
Type a friendly name for the certificate in the Friendly name text box, and then click OK.
|4. Export the SSL certificate (PFX format):|
|Open IIS Manager and navigate to the level you want to manage.
In Features View, double-click Server Certificates.
|Select the certificate you installed and click Export from the Actions pane.
In the Export Certificate dialog box, do the following:
i. Type a file name in the Export to box or click the browse button (…) to navigate to the name of a file in which to store the certificate for exporting.
ii. Type a password in the Password box if you want to associate a password with the exported certificate.
iii. Retype the password in the Confirm password box and then click OK.
|5. Install the SSL certificate (PFX) on the SQL Server:|
|On the SQL Server, click Start, and then click Run.
In the Open box, type mmc, and then click OK.
|On the File menu click Add/Remove snap-in.|
|In the Add Standalone Snap-in dialog box, click Certificates, and then click Add.|
|In the Certificates snap-in dialog box, click Computer account, and then click Next.|
|In the Select Computer dialog box, click Local computer: (the computer this console is running on), and then click Finish.|
|In the Add/Remove Snap-in dialog box, click OK.|
|In the left pane of the console, double-click Certificates (Local Computer).
Right-click Personal, point to All Tasks, and then click Import.
|On the Welcome to the Certificate Import Wizard page, click Next.|
|On the File to Import page, click Browse, locate your certificate file, and then click Next.
If the certificate has a password, type the password on the Password page, and then click Next.
|On the Certificate Store page, click Place all certificates in the following store, and then click Next.|
|Click Finish, and then click OK to confirm that the import was successful.|
|Step 2: Configure the SQL Server for SSL communication. In case a named instance is being used SSL can be enabled only on that specific instance. Databases hosted on other instances will not be affected by this configuration. You can either install an additional named instance on the same server or install a separate SQL Server in order to avoid impacting the current SQL instance.|
|In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for <server instance>, and then select Properties.|
|In the Protocols for <instance name> Properties dialog box, on the Certificate tab. Select the desired certificate from the drop down for the Certificate box.|
|On the Flags tab, in the ForceEncryption box, select Yes, and then click OK to close the dialog box.|
|Restart the SQL Server service.|
|Step 3: Stage the root CA certificate on an IIS server accessible from XenMobile Server. Port 443 should be open between the XenMobile Server and the IIS Server during the installation process in order for certificate import to work. If the XenMobile Server appliances are running on XenServer, the root certificate content can be copied to the console instead of importing it this way. If a public certificate is being used on the SQL Server, you’ll also need to import the subordinate (or issuing) CA certificates in addition to the root certificate.|
|Download the root CA cert in Base64 format (https://myca/certsrv)|
|Store it on an IIS server under C:\inetpub\wwwroot
Validate the root certificate is remotely accessible by browsing to the http://servername/certname.cer, it should appear in text format in the browser
|Step 4: Complete XenMobile Server initial configuration to enable FIPS.|
If the database configuration fails you may see one of the following errors. Complete the troubleshooting steps listed below in order to resolve the issue.
Troubleshooting: Use the certutil -v “certname” command to validate the required certificate properties exist. If any of the properties are missing recreate the certificate properly. Get more information on Cerutil tool here.
Select session_id, encrypt_options
Any sample code, scripts, SQL queries, commands, or other such information (hereafter referred to as “code”) presented in this document is provided to you AS IS with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the sample code. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.