Product Documentation

S/MIME for WorxMail

Sep 02, 2016

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

For details about S/MIME, go to Microsoft TechNet article - Understanding S/MIME.

In the following table, X indicates an S/MIME feature is supported by WorxMail on a device OS.

S/MIME Feature iOS Android Windows Phone
Digital identity provider integration

You can integrate WorxMail 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 sends certificates to the Worx shared vault, a secure storage area for sensitive app data. WorxMail obtains certificates from the shared vault.

For details, see Integrating with a Digital Identity Provider.

X    
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 WorxMail and import the certificates.

For details, see Distributing Certificates by Email.

X X X
Auto-import of single-purpose certificates

WorxMail 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 a certificate takes from the digital identity provider host to WorxMail when you integrate WorxMail with a supported third-party digital identity provider.


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

Prerequisites

WorxMail currently supports integration with Intercede MyID Identity Agent and Entrust IdentityGuard.

Configuring the Integration

  1. Prepare the identity provider app and provide it to users:
    1. To obtain a version of the MyID Identity Agent app that has the Worx Shared Vault SDK built in, go to the Citrix Ready Marketplace, search for Intercede, and click the link to request the IPA file. For Entrust, you must contact Entrust to get the .ipa to wrap.
    2. Use the MDX Toolkit to wrap the app.

      You must use a unique app ID for this app if you will deploy it to users who already have a version of the app used outside of the Worx environment. You must use the same provisioning profile for this app and WorxMail.

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

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

  2. When you add WorxMail to XenMobile, be sure to configure these policies:
    • Set the S/MIME certificate source policy to Shared vault. This means that WorxMail will use the certificates stored in its shared vault by your digital identity provider.
    • To enable S/MIME during the intial startup of WorxMail, configure the Enable S/MIME policy during first WorxMail startup policy. The policy determines whether WorxMail enables S/MIME if there are certificates in the shared vault. If no certificates are available, WorxMail prompts the user to import certificates. If the policy isn't enabled, users can enable S/MIME in the WorxMail settings.

      By default, WorxMaill does not enable S/MIME, which means the user will need to enable it through WorxMail settings.

Distributing Certificates by Email

Instead of integrating with a digital identity provider, 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 new 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 WorxMail and import the certificates. The certificates are thus available only to WorxMail. They will not appear in the iOS profile for S/MIME.

    Smart cards are not currently supported.

Prerequisites

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

  • XenMobile Server 10 or XenMobile Server 9
  • A supported version of NetScaler Gateway
  • WorxMail for iOS (minimum version 10.0.3); WorxMail for Windows Phone (minimum version 10.0.7)
  • Microsoft Windows Server 2008 R2 with Microsoft Certificate Services acting as the Root Certificate Authority (CA)
  • Microsoft Exchange:
    • Exchange Server 2013 SP1
    • Exchange Server 2013
    • Exchange Server 2010 SP3
    • Exchange Server 2010 SP2
    • Exchange Server 2007 SP1

You must 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, have all the root and intermediate certificates installed on the mobile devices.
  • Wrap WorxMail with the latest MDX Toolkit available in the Citrix downloads site.

Enabling Web Enrollment for Microsoft Certificate Services

  1. Go to Administrative Tools and 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 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 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 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 Active Directory Client Certificate Authentication is Enabled.
  7. Click Sites > Default site for Microsoft Internet Information Services > Bindings in the right pane.
  8. Add an HTTPS binding if one does not exist.
  9. Go to the Default Web Site Home.
  10. Click SSL Settings and click Accept for Client Certificates.

Creating New Certificate Templates

For the purpose of signing and encrypting email messages, Citrix recommends that you create new certificates on Microsoft Active Directory Certificate Services. In the event that 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 will duplicate 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.

  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 through Outlook mail client > Trust Center > E-mail Security > Publish to GAL (Global Address List). For details, see the Microsoft topic Add or import a certificate into Contacts.

  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


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

  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.

    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



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

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 WorxMail.

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

  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.

  2. When logged in, click Request a certificate.

  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.

  6. Click Install this certificate.
  7. Verify the certificate is installed successfully.

  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.

  10. Make sure 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 the certificates are properly installed in the domain user profile, go to Active Directory Users and Computers > View > Advanced Features.

  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.

    This figure shows a certificate to encrypt email messages.

    This figure shows a certificate to sign email messages.

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

    The way WorxMail 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, WorxMail cannot encrypt (or decrypt) a message.

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 should see both "User1" and User2" pair of certificates.

  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.

  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.

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.

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

Enabling S/MIME on WorxMail for iOS and Android

When the email has been delivered, the next step is to open the message using WorxMail and then enable S/MIME with the appropriate certificates for signing and encryption.

  1. In WorxMail, open the email message.
  2. Download the first certificate (for signing) and then tap Import certificate for Signing.

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

  4. Go to Settings to enable signing on WorxMail.

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

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

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

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

  8. Type the password assigned to the private key.

  9. Go to Settings to enable encryption on WorxMail. 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).

     

    Note: If an email is digitally signed with S/MIME, has attachments, and the recipient does not have S/MIME enabled, attachments will not be received. This is an Active Sync limitation. To effectively receive S/MIME messages, turn on S/MIME in WorxMail 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.

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

 

 


WorxMail searches the Active Directory domain for recipients' public encryption certificates. 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, even if some of them have valid keys.

localized image

 

Enabling S/MIME on WorxMail for Windows Phone

When the email has been delivered, the next step is to open the message using WorxMail for Windows Phone and then enable S/MIME with the appropriate certificates for signing and encryption.

  1. In WorxMail, open the email message.

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

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

  4. Tap settings to enable signing for WorxMail.

  5. Next to S/MIME, select the check box.

  6. In SIGNING, enable Sign Outgoing Messages and verify that the correct signing certificate is selected.

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

  8. Type the password assigned to the private key.

  9. Go to Settings and, in ENCRYPTION, tap Encrypt by Default to enable encryption for WorxMail.

 

 

Testing S/MIME on Windows Phone

If everything has been performed correctly, when User 9 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.

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