Product Documentation

S/MIME for Secure Mail

Secure Mail supports Secure/Multipurpose Internet Mail Extensions (S/MIME), enabling users to sign and encrypt messages for greater security. Signing assures the recipient that the identified sender sent the message not an imposter. Encryption allows only the recipients with a compatible certificate to open the message.

For details about S/MIME, see Microsoft TechNet.

In the following table, X indicates that Secure Mail supports an S/MIME feature on a device OS.

S/MIME Feature iOS Android
Digital identity provider integration: You can integrate Secure Mail with a supported third-party digital identity provider. Your identity provider host supplies certificates to an identity provider app on user devices. That app sends certificates to the XenMobile shared vault, a secure storage area for sensitive app data. Secure Mail obtains certificates from the shared vault. For details, see Integrating with a Digital Identity Provider. X  
Derived Credential support Secure Mail supports the use of derived credentials as a certificate source. For more information on derived credentials, see Derived Credentials for iOS.  
Certificate distribution by email: Distributing certificates by email requires that you create certificate templates and then use those templates to request user certificates. After you install and validate the certificates, you export the user certificates and then email them to users. Users then open the email in Secure Mail and import the certificates. For details, see Distributing Certificates by Email. X X
Auto-import of single-purpose certificates: Secure Mail detects if a certificate is only for signing or encryption and then automatically imports the certificate and notifies the user. If a certificate is for both purposes, users are prompted to import it. X  

Integrating with a digital identity provider

The following diagram shows the path that a certificate takes from the digital identity provider host to Secure Mail. This happens when you integrate Secure Mail with a supported third-party digital identity provider.

Image of the digital identity provider certificate path to Secure Mail

The MDX shared vault is a secure storage area for sensitive app data such as certificates. Only XenMobile enabled apps can access the shared vault.

Prerequisites

Secure Mail supports integration with Entrust IdentityGuard.

Configuring the integration

  1. Prepare the identity provider app and provide it to users:
    • Contact Entrust to get the .ipa to wrap.
    • Use the MDX Toolkit to wrap the app.

      If you deploy this app to users who already have a version of the app outside of the XenMobile environment, use a unique app ID for this app. Use the same provisioning profile for this app and Secure Mail.

    • Add the app to XenMobile and publish it to the XenMobile Store.
    • Let your users know that they must install the identity provider app from Secure Hub. Provide guidance, as needed, about any post-installation steps.

      Depending on how you configure the S/MIME policies for Secure Mail in the next step, Secure Mail might prompt users to install certificates or enable S/MIME in Secure Mail settings. Steps for both of those procedures are in Enabling S/MIME on Secure Mail for iOS.

  2. When you add Secure Mail to XenMobile, be sure to configure these policies:

    • Set the S/MIME certificate source policy to Shared vault. This setting means that Secure Mail uses the certificates stored in its shared vault by your digital identity provider.

    • To enable S/MIME during the initial startup of Secure Mail, configure the Enable S/MIME during first Secure Mail startup policy. The policy determines if Secure Mail enables S/MIME when there are certificates in the shared vault. If no certificates are available, Secure Mail prompts the user to import certificates. If the policy isn’t enabled, users can enable S/MIME in the Secure Mail settings. By default, Secure Mail does not enable S/MIME, which means that users must enable S/MIME through Secure Mail settings.

Using derived credentials

Instead of integrating with a digital identity provider, you can allow the use of derived credentials.

When you add Secure Mail to XenMobile, configure the S/MIME certificate source policy to Derived Credentials. For more information on derived credentials, see Derived Credentials for iOS.

Distributing certificates by email

Instead of integrating with a digital identity provider or using derived credentials, you can distribute certificates to users by email. This option requires the following general steps, detailed in this section.

  1. Use Server Manager to enable web enrollment for Microsoft Certificate Services and to verify your authentication settings in IIS.

  2. Create certificate templates for signing and encrypting email messages. Use those templates to request user certificates.

  3. Install and validate the certificates, then export the user certificates and email them to users.

  4. Users open the email in Secure Mail and import the certificates. The certificates are thus available only to Secure Mail. They do not appear in the iOS profile for S/MIME.

Prerequisites

The instructions in this section are based on the following components:

  • XenMobile Server 10 and later
  • A supported version of NetScaler Gateway
  • Secure Mail for iOS (minimum version 10.8.10); Secure Mail for Android devices (minimum version 10.8.10)
  • Microsoft Windows Server 2008 R2 or later with Microsoft Certificate Services acting as the Root Certificate Authority (CA)
  • Microsoft Exchange:
    • Exchange Server 2016 Cumulative Update 4
    • Exchange Server 2013 Cumulative Update 15
    • Exchange Server 2010 SP3 Update Rollup 16

Complete the following prerequisites before configuring S/MIME:

  • Deliver the root and intermediate certificates to the mobile devices either manually or through a credentials device policy in XenMobile. For details, see Credentials device policies.
  • If you are using private server certificates to secure the ActiveSync traffic to Exchange Server, do the following: Have all the root and intermediate certificates installed on the mobile devices.

Enabling Web Enrollment for Microsoft Certificate Services

  1. Go to Administrative Tools and the select Server Manager.
  2. Under Active Directory Certificate Services, check to see if Certificate Authority Web Enrollment is installed.
  3. Select Add Role Services to install Certificate Authority Web Enrollment, if needed.
  4. Check Certificate Authority Web Enrollment and then click Next.
  5. Click Close or Finish when the installation is complete.

Verifying your authentication settings in IIS

  • Ensure that the Web enrollment site used to request user certificates (for example, https://ad.domain.com/certsrv/) is secured with an HTTPS server certificate (private or public).
  • The Web enrollment site must be accessed through HTTPS.
  1. Go to Administrative Tools and then select Server Manager.
  2. In Web Server (IIS), look under Role Services. Verify that Client Certificate Mapping Authentication and IIS Client Certificate Mapping Authentication are installed. If not, install these role services.
  3. Go to Administrative Tools and then select Internet Information Services (IIS) Manager.
  4. In the left pane of the IIS Manager window, select the server running the IIS instance for web enrollment.
  5. Click Authentication.
  6. Ensure that Active Directory Client Certificate Authentication is Enabled.
  7. Click Sites > Default site for Microsoft Internet Information Services > Bindings in the right pane.
  8. If an HTTPS binding does not exist, add one.
  9. Go to the Default Web Site Home.
  10. Click SSL Settings and then click Accept for Client Certificates.

Creating new certificate templates

To sign and encrypt email messages, Citrix recommends that you create certificates on Microsoft Active Directory Certificate Services. If you use the same certificate for both purposes and archive the encryption certificate, it is possible to recover a signing certificate and allow impersonation.

The following procedure duplicates the certificate templates on the Certificate Authority (CA) server:

  • Exchange Signature Only (for Signing)
  • Exchange User (for Encryption)
  1. Open the Certificate Authority snap-in.

  2. Expand the CA and then go to Certificate Templates.

  3. Right-click and then click Manage.

  4. Search for the Exchange Signature Only template, right-click the template and then click Duplicate Template.

    Image of the Exchange Signature Only template

  5. Assign any name.

  6. Select the Publish certificate in Active Directory check box.

    Note:

    If you do not select the Publish certificate in Active Directory check box, users must publish the user certificates (for signing and encryption) manually. They can do this through Outlook mail client > Trust Center > Email Security > Publish to GAL (Global Address List).

    Image of the Publish certificate in Active Directory check box

  7. Click the Request Handling tab and then set the following parameters:

    • Purpose: Signature
    • Minimum key size: 2048
    • Allow private key to be exported check box: selected
    • Enroll subject without requiring any user input check box: selected

    Image of the Request Handling tab

  8. Click the Security tab and, under Group or user names, ensure that Authenticated Users (or any desired Domain Security Group) is added. Also ensure that, under Permissions for Authenticated Users, the Read and Enroll check boxes are selected for Allow.

    Image of the Security tab

  9. For all other tabs and settings, leave the default settings.

  10. In Certificate Templates, click Exchange User and then repeat steps 4 though 9.

    Image of the Certificate Templates dialog box

    For the new Exchange User template, use the same default settings as for the original template.

  11. Click the Request Handling tab and then set the following parameters:

    • Purpose: Encryption
    • Minimum key size: 2048
    • Allow private key to be exported check box: selected
    • Enroll subject without requiring any user input check box: selected

      Image of the Request Handling tab

      Image of the Authenticated Users group

  12. When both templates are created, be sure to issue both certificate templates. Click New and then click Certificate Template to Issue.

    Image of the New Certificate Template to Issue option

Requesting user certificates

This procedure uses “user1” to navigate to the Web enrollment page; for example, https://ad.domain.com/certsrv/. The procedure requests two new user certificates for secure email: one certificate for signing and the other for encryption. You can repeat the same procedure for other domain users that require the use of S/MIME through Secure Mail.

Manual enrollment is used through the Web enrollment site (example, https://ad.domain.com/certsrv/) on Microsoft Certificate Services to generate the user certificates for signing and encryption. An alternative is to configure auto-enrollment through a Group Policy for the group of users who would use this feature.

  1. On a Windows-based computer, open Internet Explorer and go to the Web enrollment site to request a new user certificate.

    Note:

    Be sure you log on with the correct domain user to request the certificate.

    Image of the web enrollment site

  2. When logged in, click Request a certificate.

    Image of the Request a certificate option

  3. Click Advanced Certificate Request.

  4. Click Create and Submit a request to this CA.

  5. Generate the user certificate for signing purposes. Select the appropriate template name and type your user settings, and then next to Request Format, select PKCS10.

    The request has been submitted.

    Image of the Advanced Certificate Request option

  6. Click Install this certificate.

  7. Verify that the certificate is installed successfully.

    Image of the installation success confirmation

  8. Repeat the same procedure but now for encrypting email messages. With the same user logged on to the Web enrollment site, go to the Home link to request a new certificate.

  9. Select the new template for encryption and then type the same user settings you entered in step 5.

    Image of the new template option

  10. Ensure you installed the certificate successfully and then repeat the same procedure to generate a pair of user certificates for another domain user. This example follows the same procedure and generates a pair of certificates for “User2”.

    Note:

    This procedure uses the same Windows-based computer to request the second pair of certificates for “User2”.

Validating Published Certificates

  1. To ensure that the certificates are properly installed in the domain user profile, go to Active Directory Users and Computers > View > Advanced Features.

    Image of the Advanced Features option

  2. Go to the properties of the user (User1 for this example) and then click the Published Certificates tab. Ensure that both certificates are available. You can also verify that each certificate has a specific usage.

    Image of the Published Certificates tab

    This figure shows a certificate to encrypt email messages.

    Image of the certificate to encrypt email messages

    This figure shows a certificate to sign email messages.

    Image of the certificate to sign email messages

    Ensure that the correct encrypted certificate is assigned to the user. You can verify this information under Active Directory Users and Computers > user properties.

    Image of the user properties image

    The way Secure Mail works is by checking the userCertificate user object attribute via LDAP queries. You can read this value on the Attribute Editor tab. If this field is empty or has the incorrect user certificate for encryption, Secure Mail cannot encrypt (or decrypt) a message.

    Image of the Attribute Editor tab

Exporting the user certificates

This procedure exports both “User1” and “User2” pair certificates in .PFX (PKCS#12) format with the private key. When exported, the certificates are sent through email to the user using Outlook Web Access (OWA).

  1. Open the MMC console and go to the snap-in for Certificates - Current User. You see both “User1” and User2” pair of certificates.

    Image of the Certificate current users

  2. Right-click the certificate and then click All Tasks > Export.

  3. Export the private key by selecting Yes, export the private key.

  4. Select the Include all certificates in the certification path if possible and Export all extended properties check boxes.

    Image of the Personal Information Exchange options

  5. When you export the first certificate, repeat the same procedure for the remaining certificates for users.

    Note:

    Clearly label which certificate is the signing certificate and which certificate is the encryption certificate. In the example, the certificates are labeled as userX-sign.pfx and “userX-enc.pfx.

    Image of the certificate labels

Sending certificates through email

When all certificates are exported in PFX format, you can use Outlook Web Access (OWA) to send them through email. The logon name for this example is User1 the sent email contains both certificates.

Image of the OWA mail to send certificates

Repeat the same procedure for User2 or other users in your domain.

Enabling S/MIME on Secure Mail for iOS and Android

After the email is delivered, the next step is to open the message using Secure Mail and enable S/MIME with the appropriate certificates for signing and encryption.

  1. In Secure Mail, open the email message.

  2. Download the first certificate (for signing) and then tap Import certificate for Signing.

    Image of the Import certificate for signing option

  3. Type the password assigned to the private key when the certificate was exported.

    Image of the private key password option

  4. Go to Settings to enable signing on Secure Mail.

  5. Tap S/MIME and next to Signing, tap Off.

    Image of the Secure Mail S/MIME setting

  6. In Signing, enable and verify that the correct signing certificate is selected.

    Image of the signing certificate confirmation

    This figure shows signing enabled with user certificate (for signing).

    Image of the signing options enabled

  7. Go back to the email message to download and import the certificate for encryption.

    Image of the import certificate for encryption option

  8. Type the password assigned to the private key.

    Image of the password prompt

  9. Go to Settings to enable encryption on Secure Mail. Next to Encrypt by Default, tap Off. Ensure that the correct user certificate is selected for encryption.

    This figure shows encryption enabled with user certificate (for encryption).

    Image of the enabled encryption option

    Note:

    If an email is digitally signed with S/MIME, has attachments, and the recipient does not have S/MIME enabled, attachments are not received. This behavior is an Active Sync limitation. To receive S/MIME messages effectively, turn on S/MIME in Secure Mail settings.

Testing S/MIME on iOS and Android

If everything has been performed correctly, when User1 or User2 sends an email signed and encrypted, the recipient can read the message.

The following figure shows an example of an encrypted message read by the recipient.

Image of the encrypted message

The following figure shows an example of verification of signed trusted certificate.

Image of a verified signed certificate

Secure Mail searches the Active Directory domain for public encryption certificates of recipients. If a user sends an encrypted message to a recipient who does not have a valid public encryption key, the message is sent unencrypted. In a group message, if even one recipient doesn’t have a valid key, the message is sent unencrypted to all recipients.

Image of an unencrypted email

Configuring public certificate sources

To use S/MIME public certificates, configure the S/MIME public certificate source, LDAP server address, LDAP Base DN, and Access LDAP Anonymously policies.

In addition to the app policies, do the following.

  • If the LDAP servers are public, ensure that the traffic goes directly to LDAP servers. To do so, configure the network policy for Secure Mail to be Tunneled to the internal network and configure split DNS for NetScaler.
  • If the LDAP servers are on an internal network, do the following:
    • For iOS, ensure that you don’t configure the Background network service gateway policy. If you do configure the policy, users receive frequent authentication prompts.
    • For Android, ensure that you add the LDAP server URL in the list for the Background network service gateway policy.