Client Certificates for BlackBerry Work

Client Certificates for BlackBerry Work Product Guide Supplemental BlackBerry Work Product Version: 2.6 Last Updated: 21-Feb-17

Legal Notice 2017 BlackBerry Limited. Trademarks, including but not limited to BLACKBERRY, BES, EMBLEM Design, ATHOC, EMBLEM Design, ATHOC & Design and PURPLE GLOBE Design, GOOD, GOOD WORK, LOCK Design, MANYME, MOVIRTU, SECUSMART, SECUSMART & Design, SECUSUITE, SECUVOICE, VIRTUAL SIM PLATFORM, WATCHDOX and WORKLIFE are the trademarks or registered trademarks of BlackBerry Limited, its subsidiaries and/or affiliates, used under license, and the exclusive rights to such trademarks are expressly reserved. All other trademarks are the property of their respective owners. All other trademarks are the property of their respective owners. This documentation is provided "as is" and without condition, endorsement, guarantee, representation or warranty, or liability of any kind by BlackBerry Limited and its affiliated companies, all of which are expressly disclaimed to the maximum extent permitted by applicable law in your jurisdiction. 2

Revision History Date Description 7-Sep-15 Initial publication 30-Nov-15 Updated for BEMS 2.0. Updates "Configuring Directory Lookup in BEMS." 05-Jan-16 Updated for BlackBerry Work 2.0. 29-Feb-16 Adding user policies for 2.1 07-June-16 Adding additional BlackBerry Work client certificate information. Changing document name. 23-Jan-17 Rebranded for BlackBerry 3

Contents Legal Notice...2 Revision History...3 Client Certificate Prerequisites...5 Configuring Good Control for Client Certificates...5 Install Root and Intermediate CA Certificates...5 Whitelist Applications for Access to Private Keys...5 Enable PKCS12 Certificate Management...5 Client Certificate Distribution Options...6 Manual...6 Using Self Service Portal...6 Automated...6 Configuring BlackBerry Work for CBA or PKINIT...7 What is PKINIT...7 Requirements for CBA or PKINIT...7 BlackBerry JSON Configuration...7 Understanding S/MIME...7 Digital Signatures...8 Message Encryption...8 Configuring Directory Lookup in BEMS...9 Configuring BlackBerry Work for S/MIME... 10 Check the BlackBerry Work Application Server List... 10 Setting User Policies... 10 4

Client Certificate Prerequisites Ensure that your BlackBerry Dynamics-BEMS environment includes at the minimum: Good Control 2.x Good Proxy 2.x BEMS 1.5.x See BlackBerry Dynamics Server Deployment Planning and Installation and the BEMS Administration Guide, respectively, for detailed instructions. Configuring Good Control for Client Certificates The process of configuring GC for Client Certificates consists of: Installing root and intermediate CA certificates Whitelisting GD apps supporting the installed certificates Enabling PKCS12 Certificate Management Each major step is addressed in sequence below. First, however, login to Good Control as an administrator. Install Root and Intermediate CA Certificates Upon obtaining the necessary CA certificates, you will need to install them in Good Control. To install the root and intermediate certificates: 1. Under SETTINGS, click Certificates. 2. With the TRUSTED AUTHORITIES tab open, click to upload each new certificate. 3. Click Apply. Whitelist Applications for Access to Private Keys Next, you will need add the GD apps that will use/support the installed certificates. To add applications that will have access to any of the user's configured private keys (if any): 1. If not already open, click Certificates under SETTINGS, then click the APP USAGE tab. 2. Click Add App. 3. Select the apps to whitelist, then click OK. Enable PKCS12 Certificate Management The next step in configuring S/MIME in Good Control is to define the policy sets governing S/MIME to use PKCS12 certificate management. 5

To enable PKCS12 Certificate Management: 1. Under POLICIES, click Policy Sets. 2. Search for or scroll down to policy set you need to modify and click it (or clone an existing policy by clicking its corresponding ). 3. With the SECURITY POLICIES tab open, scroll down to Certificate Management. 4. Select BlackBerry Dynamics and Device Certificate Store, then check Allow use of client certificates. 5. Click Update. Client Certificate Distribution Options Client certificates can be distributed manually by either the end user (via self-service) or the administrator. They can also be distributed in a more automated fashion using Certificate Definitions. Manual Manual certificate distribution can either be done by the end user as long as self-service is enabled or by a Good Control Administrator. Using Self Service Portal 1. Login to Good Control 2. Open the Certificates tab, then click Upload and Browse for the desired PFX or P12 certificate file. In order to be prompted to install the client certificate, you must be in a policy set that is in accordance with Allow use of client certificates above). 3. Select the certificate file, then click Upload. Administrator 1. Login to Good Control, then click Users and Groups under USERS. 2. Search for and select the desired user by clicking the corresponding checkbox, then select Edit User from the User Actions listbox. 3. Open the Certificates tab, then click Upload and Browse for the desired PFX or P12 certificate file. In order to be prompted to install the client certificate, you must be in a policy set that is in accordance with Allow use of client certificates above). 4. Select the certificate file, then click Upload. 5. On the activated device, when prompted by the BlackBerry Work client, enter the correct P12 password for the client certificate. Automated Client certificates can be automatically distributed to BlackBerry Dynamics applications including BlackBerry Work by creating a Certificate Definition in the Good Control console. 6

To configure Certificate Definitions: 1. If not already open, click Certificates under SETTINGS, then click the CERTIFICATE DEFINITIONS tab. 2. Click Add Add Definition, fill in the name and click Add. 3. Fill in the required information, then click Save. Configuring BlackBerry Work for CBA or PKINIT The BlackBerry Work client supports both certificate based authentication (CBA) as well as PKINIT for authenticating to Exchange ActiveSync (EAS) and Exchange Web Services (EWS). It can also support mixed mode where the client uses CBA for EAS and PKINIT for EWS. What is PKINIT PKINIT is a protocol that uses public key cryptography for initial authentication with regards to Kerberos. Requirements for CBA or PKINIT When an appropriate client certificate is installed, BlackBerry Work will negotiate with the backend system to decide whether to authenticate using certificate based authentication or PKINIT. In order for PKINIT to work properly the following client certificate properties must be populated: Enhanced Key Usage (EKU) must include Smart Card Logon User Principal Name (UPN) must be populated in the Subject Alternative Name (SAN) In addition to the above, Kerberos Constrained Delegation must not be enabled on the Good Control. BlackBerry JSON Configuration In order to force BlackBerry Work to only use certificate based authentication or PKINIT, the following JSON variable must be added: useeasauthcert : true Understanding S/MIME Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard of public key encryption and signing of MIME data. S/MIME provides the cryptographic security services for electronic messaging applications, including: authentication message integrity non-repudiation of origin (using digital signatures) privacy and data security (using encryption) 7

S/MIME specifies the MIME type application/pkcs7-mime (smime-type "enveloped-data") for data enveloping (encrypting) where the whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity. Before S/MIME, Simple Mail Transfer Protocol (SMTP) was and remains widely used, but it is inherently not secure. With S/MIME, you now have an e-mail option that is both more secure and widely accepted. S/MIME is as important a standard as SMTP because it brings SMTP to the next level: allowing widespread e-mail connectivity without compromising security. 1 Digital Signatures Authentication, nonrepudiation, and data integrity are the core functions of digital signatures. Together, they ensure recipients that the message came from the sender, and that the message received is the message that was sent. At its simplest, a digital signature works by performing a signing operation on the text of the e-mail message when the message is sent, and a verifying operation when the message is read. The signing operation performed when the message is sent requires information that can be supplied only by the sender. This information is used in a signing operation by capturing the e-mail message and performing a signing operation on the message. This operation produces the actual digital signature, which is then appended to the e- mail message. The process comprises the following steps: Because this operation requires unique information from the sender, digital signatures provide authentication and nonrepudiation, proving that the message could only have come from the sender. However, the sender's information used to verify the signature is different than that provided by the sender when the message was signed. This lets the recipient verify the sender's unique information without actually knowing that information, thus protecting the sender's information. Message Encryption Confidentiality and data integrity provide the core functions of message encryption. They ensure that only the intended recipient can view a message and that the message received is the message that was sent. Message encryption makes the text of a message unreadable by performing an encryption operation on it when it is sent. When the message is received, the text is made readable again by performing a decryption operation when the message is read. The encryption operation performed when the message is sent captures the e-mail message and encrypts it using information specific to the intended recipient. The encrypted message replaces the original message, and then the message is sent to the recipient. 8

Important: Although message encryption provides confidentiality, it does not authenticate the message sender in any way. An unsigned, encrypted message is as susceptible to sender impersonation as an unencrypted message. Because nonrepudiation is a direct result of authentication, message encryption also does not provide nonrepudiation. Although encryption provides data integrity, an encrypted message can show only that the message has not been altered since it was sent. No information about who sent the message is provided. To prove the identity of the sender, the message must use a digital signature. When the recipient opens an encrypted message, a decryption operation is performed on the encrypted message. The encrypted message and the recipient's unique information are both retrieved. The recipient's unique information is then used in a decryption operation performed against the encrypted message. This operation returns the unencrypted message, which is then shown to the recipient. If the message has been altered in transit, the decryption operation will fail. Digital signatures and message encryption are not mutually exclusive services. Each service addresses specific security issues. Digital signatures address authentication and repudiation issues, and message encryption addresses confidentiality issues. The two services are designed to be used in conjunction with one another, because each separately addresses one side of the sender-recipient relationship. Digital signatures address security issues related to senders, and encryption addresses security issues primarily related to recipients. Configuring Directory Lookup in BEMS To configure BEMS for LDAP lookup: 1. Log on to the BEMS Dashboard and proceed to Mail/Certificate Directory Lookup. 2. Select the lookup sources you would like the BEMS server to utilize (multiple can be selected) and click Save. 3. If you plan to utilize LDAP, fill in the additional variables after clicking on Enable LDAP Lookup. a. LDAP Server Name (required) b. LDAP Server Port (required) c. LDAP User Name Query Template (optional) d. LDAP Base DN (optional) e. Authentication Type (optional) 4. Once all of the appropriate variables are filled in, you can type in a test email address to perform a test LDAP query. 5. If the test succeeds, click on Save. For BlackBerry Work S/MIME users on Android, also ensure that you have Android Push Notifications configured as this is utilized for Public Certificate Lookups: 1. Log on to the BEMS Dashboard and proceed to Mail/Android Push Notification. 2. Enter the GCM Sender ID as well as the GCM API Key and click Save. 9

Configuring BlackBerry Work for S/MIME The process of configuring GC for S/MIME consists of: I. Verifying that the BlackBerry Work app is correctly configured for BEMS II. Setting User Policies Each major step is addressed in sequence below. First, however, login to Good Control as an administrator. Check the BlackBerry Work Application Server List First, you'll need to very that the correct version of bems is included as an application server for BlackBerry Work. To verify that BlackBerry Work is correctly configured for BEMS: 1. Under APPS, click Manage Apps, then search or scroll down to the pertinent version of BlackBerry Work (1.5.x or higher) and click it. 2. Click the BLACKBERRY DYNAMICS tab. 3. Make sure the right BEMS host on port 8443 is set. If BEMS doesn't appear in the list and/or you need to add BEMS machine(s), see "Adding BEMS to the BlackBerry Work Application Server List" in the BlackBerry Product Guide. Setting User Policies To configure S/MIME specific user policies: 1. Under POLICIES, click Policy Sets. 2. Search for or scroll down to policy set you need to modify and click it (or clone an existing policy by clicking its corresponding ). 3. With the APPS tab open, open the App Specific Policies list, scroll down to BlackBerry Work, and open the S/MIME tab. 4. Available policies include: Enhanced Security Periodically require PIN entry to access S/MIME capabilities Sending Require all emails to be signed (Signing algorithm SHA-128, 256, 512 (default)) Require all emails to be encrypted (Default encryption algorithm 3DES, AES-128, AES-256 (default)) Receiving 10

Automatically download the body of S/MIME emails (Never (default), Always, Over WiFi Only) (Automatic S/MIME body download over WiFi is only supported on Android for now. When selected, on ios it will default to Never.) Perform name checking (verify email address in certificate matches user's account) Certificate Management Clear public certificate cache (Daily, Weekly, Monthly (default), Never) Revocation Checking Select depth of certificate checking (Check entire certificate chain (default), Check user / client certificate only) Use AIA extension in certificate if present Default OCSP URL <URL> (Default OCSP URL used if not permitted to use AIA extension or AIA extension is not present in certificate.) 11