SSL Certificate Format Definition and Converting examples using openssl

This is more for my reference, but I thought I would share the information for those that struggled with this as I did.  The first section defines the different types of formats that can be used for certificates, and when / how / and by who they are used.  The second section provides examples of how to convert between the different formats using openssl.

Certificate Format Definitions

PEM Format

The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

DER Format

The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms. The SSL Converter can only convert certificates to DER format. If you need to convert a private key to DER, please use the OpenSSL commands on this page.

PKCS#7/P7B Format

The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extention of .p7b or .p7c. P7B certificates contain “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format

The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

When converting a PFX file to PEM format, OpenSSL will put all the certificates and the private key into a single file. You will need to open the file in a text editor and copy each certificate and private key (including the BEGIN/END statments) to its own individual text file and save them as certificate.cer, CACert.cer, and privateKey.key respectively.

OpenSSL Command syntax examples

OpenSSL Convert PEM

Convert PEM to DER

openssl x509 -outform der -in certificate.pem -out certificate.der

Convert PEM to P7B

openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer

Convert PEM to PFX

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

OpenSSL Convert DER

Convert DER to PEM

openssl x509 -inform der -in certificate.cer -out certificate.pem

Openssl Convert CRT

Convert CRT to PEM

openssl x509 -in mycert.crt -out mycert.pem -outform PEM

OpenSSL Convert P7B

Convert P7B to PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

Convert P7B to PFX

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer

OpenSSL Convert PFX

Convert PFX to PEM

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

This information was taken almost directly from the following link.  Thank you SSLShopper for providing this information.

https://www.sslshopper.com/ssl-converter.html

Authentication Using Kerberos Constrained Delegation

I would like to start off by saying that a large part of this documentation was obtained from MobileIron documentation that can be obtained from the MobileIron support site.  I am simply adding to to it and updating things that I found to be more difficult.

About Kerberos Constrained Delegation and MobileIron

Starting at VSP version 4.5.3 and later and Sentry version 3.3 and later, you can use Kerberos constrained delegation for authentication.  To use Kerberos constrained delegation, you need to already have a Kerberos environment set up that includes the following components:

  • Kerberos Key Distribution Center (KDC) A Kerberos Key Distribution Center (KDC) is a service on the Active Directory server that serves as an authentication service and supplies session tickets and keys to users and computers within the Active Directory domain.
  • Active Directory (AD) and Exchange Server  Active Directory is a directory service that authenticates and authorizes all users and computers in the associated Windows network.  The server that runs Active Directory is also called a domain controller.
  • Exchange Server  The following configurations are supported (however it has been successful with Exchange 2013 as well):
  • Exchange 2007 SP3 with AD 2003
  • Exchange 2010 SP1/SP2 with AD 2008 R2
  • Client Access Server (CAS)  One the server roles for Exchange Server. CAS supports Exchange ActiveSync applications.  It accepts connections to the Exchange server from different clients.
  • Exchange ActiveSync (EAS)  A data protocol for syncing data (email, contacts, calendar, tasks) between mobile devices and Exchange.  These components can exist on separate servers or on one server.

The following diagram shows the flow of information among the servers and MobileIron components.  The majority of these steps happen just one time.  Once the service token is cached on Sentry, the device accesses Exchange without requiring authentication for subsequent communication with Exchange until the token expires.

 
mobileiron-kerberos-communication
 

The steps that correlate with the numbers in the diagram above are listed below with a description of what is happening with each step:

Step Description
1 Configure the VSP for Kerberos and VSP sends Sentry the certificate with the Kerberos
configuration when the configuration is saved. Sentry reboots after receiving the configuration information from the VSP.
2 VSP pushes the SCEP profile that you configured for Kerberos and the trusted root certificate to the device on check-in.
3 After Sentry reboots (step 1), it connects to the KDC and requests a proxyable, renewable, and forwardable service token, configured for the Sentry SPN.
4 The KDC returns the service token for the configured Sentry’s SPN to the Sentry. The Sentry caches this token.
5 A device sends a request for Exchange access along with the cert, received in step 2, to Sentry. Sentry receives the request from the device and extracts the device UPN from the certificate.
6 Sentry sends the service token (received in step 4) and the device UPN to the KDC.
7 The KDC generates a device service token and returns it to Sentry.
8 Sentry inserts the device service token (received in step 7) into the ActiveSync request and forwards the request to the CAS server.
9 Exchange responds by sending the requested information (for example, email) to Sentry and Sentry forwards the requested information to the device.

Notes: Ports 88 (UDP and TCP) and 389 (TCP) between Active Directory and Sentry (or port 636 (TCP) if you are using SSL-enabled Active Directory) need to be opened to allow communication.  Port 88 is used for Kerberos protocol communication.  Port 389 (or 636) is used for the LDAP ping between Sentry and the KDC to verify that the KDC IP is the same as the Active Directory IP.

If Windows Server 2003 is being used, the KDC may listen for requests on port 88 using UDP
instead of TCP.  You can force Kerberos to use TCP instead of UDP by changing the MaxPacketSize
from 0 to 1 in the registry editor.  For information about how to do this, refer to the following
Microsoft KB article: http://support.microsoft.com/kb/244474.

Configuration Overview

The following steps are required to set up Sentry for Kerberos authentication:
Step Action(s)
1 Verify IP Connectivity Between Sentry, AD, KDC, and Exchange.
2 Verify that Sentry, KDC, and Exchange are Syncing Network Time.
3 Create a Kerberos Service Account on the KDC For Each Sentry.
4 Map the Sentry Service Account to the servicePrincipalName.
5 Configure Constrained Delegation For Sentry Service Accounts.
6 Verify the Group Policy Values.
7 Enable the Kerberos Protocol on the Exchange Server.
8 Set Up SCEP for Kerberos Authentication.
9 Set Up the Exchange Profile for Kerberos Authentication.
10 Configure Device Authentication.
11 Set up Kerberos Notifications.
12 Validate the Kerberos Configuration.

Verify IP Connectivity Between Sentry, AD, KDC, and Exchange

The Active Directory server and the KDC server are typically the same server.  Before you configure Kerberos, ensure that there is IP connectivity between Sentry, the KDC server, and Exchange. For example, verify firewall ports and DNS resolution of the server names.

Verify that Sentry, KDC, and Exchange are Syncing Network Time

Sentry, the KDC, and Exchange servers must not have a time skew of more than five minutes
(the default on the KDC server).  If the time skew is more than five minutes, the Exchange server
assumes that the service token has been spoofed or manipulated and will not accept it.  The best way to avoid a time skew is to set up the servers to sync network time.

To configure Sentry to sync network time:

  1. Log in to the Sentry using the configuration URL (https://<servername>.<companyname>.com:8443).
  2. Select the Settings tab
  3. Select Date and Time (NTP) in the left panel
  4. Set the Primary NTP Server to the same NTP server that KDC and Exchange are using
  5. Click Apply

mobileiron-set-ntp-time-sync

Create a Kerberos Service Account on the KDC For Each Sentry

To facilitate communication among KDC server, Exchange server, and Sentry, a Kerberos service account is set up for Sentry on the KDC server (usually on the Active Directory server).  If multiple Sentries are being used, it is recommended best practice to set up a service account for each Sentry on the Active Directory server.

MobileIron recommends that you create a separate service account on the KDC for each Sentry.  Having separate accounts for each Sentry assists in auditing and is especially useful in a multidomain configuration, but is not a requirement.

To create a Kerberos service account:

  1. Log in to your KDC server as an administrator
  2. From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.  A browser appears that displays the Active Directory domains
  3. Expand the realm (Kerberos refers to a domain as a realm)
  4. Right-click Users and select New > User
  5. Enter the First Name and Last Name for the Kerberos service account.  The Full Name field is auto-populated.
  6. Enter the User Logon Name, preceded by HTTP/
  7. Choose the realm name from the drop-down list next to the User Logon Name field
  8. Delete the HTTP/ from the User Logon Name (pre-Windows 2000) field.  When you entered the User Logon Name in step 6, the User Logon Name (pre-Windows 2000) field auto-populated with the same string, but the slash (/) is not a valid character for this field.  Remove the slash and HTTP from the string in this input field.
  9. Click Next
  10. Enter and confirm the password
  11. Check (or uncheck) the password and account options depending on the organization’s policies.  If your company password policy allows, select Password Never Expires.  If this isn’t possible, plan a maintenance cycle where you update the password and/or create a new keytab for the
    Sentry configuration on the VSP.  If the passwords take a long time to propagate across the domain, you can use two service accounts per Sentry, rotating the service accounts as their passwords are about to expire.  Because this is a Sentry configuration change, Sentry will reboot causing a disruption of email traffic for a short time.
  12. Click Next
  13. Click Finish

The new user account now appears in the Users list. If you have multiple Sentries, MobileIron recommends that you create a service account for each.  Note that if you change the password for the Kerberos service account after you generate the keytab, Kerberos will not be able to renew the service token.  When the service token expires the user will no longer have access to email.  If the password is changed for the service account, a new keytab must be generated as described in the section titled Map the Sentry Service Account and Create a Keytab and it must be uploaded to the VSP as described in the section titled Configure Device Authentication.

Verify Realm in User Account Properties

Ensure that the realm is specified for each of the newly created service account(s).

The steps to verify the realm for the new service account(s):

  1. Right-click the new account in the Users list
  2. Select Properties
  3. Select the Account tab
  4. Select the realm from the drop-down list, if it is not already there  You can also make changes to the Account Options in this tab.
  5. Click OK

Map the Sentry Service Account to the servicePrincipalName

After you map the Sentry service account to the servicePrincipalName, the Delegation tab appears in the User Account Properties.  The delegation tab is required for the next step, Configure Constrained
Delegation For Sentry Service Accounts.

In this step you use the ktpass command on the KDC to perform one of the following two procedures:

  • Map the Sentry Service Account and Create a Keytab (optional)
    Generating a keytab is optional. A keytab is a file that stores domain credentials so that Sentry can log into Kerberos without being prompted for a password. When you configure Sentry for Kerberos authentication you can upload the keytab file.
  • Map the Sentry Service Account to the ServicePrincipalName (SPN)
    You can map the Sentry service account to the servicePrincipalName without creating a keytab.

Note: If a keytab is not generated, the Realm, Sentry Service Principal, Password, and Key Distribution Center information is entered into the Kerberos Configuration form, as explained in the About Kerberos Constrained Delegation section.

Map the Sentry Service Account and Create a Keytab

When you create a keytab, the Sentry service account is concurrently mapped to the servicePrincipalName.

To generate a keytab:

  1. On the KDC server, open a command prompt window
  2. At the prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>

Note: the realm must be in all uppercase.  This is characteristic of Kerberos.
Below is an example:

ktpass /out sentry1_eas_kcd.keytab /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1

where sentry1_eas_kcd.keytab is the filename that you will upload to Sentry.  The returned information for the above example looks like this:

Targeting domain controller: dc_01.texas.ironmobile.com
Using legacy password setting method
Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to sentry1_eas_kcd.keytab:
Keytab version: 0x502
keysize 74 HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM ptype 0 (KRB5_NT_UNKNOWN)
vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x0d9d8f20b3d46f65b2cdb5cc9ec3167b)

Note: the warning can be ignored.

The keytab (in this example, sentry1_eas_kcd.keytab) is saved in the current working directory or where the command was entered.  To specify another location to save, simply include the full path in front of the filename.  For example, if the file is to be saved in the Desktop folder of the Administror account, sentry1_eas_kcd.keytab would be replaced with c:\Users\Administrator\Desktop\sentry1_eas_kcd.teytab.  This file should be copied to a location that is accessible when configuring Sentry in the VSP.  The file will be uploaded to the VSP.  Repeat this procedure to create a keytab for each Sentry / Sentry Service Account in the system.

Note: If the password for the service account changes, a new keytab file must be created and uploaded to the VSP before the current service token expires.  Failure to upload the new keytab file before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.

Map the Sentry Service Account to the ServicePrincipalName (SPN)

To map the Sentry Service account to the servicePrincipalName:

  1. On the KDC server, open a command window
  2. At the command prompt, type the following command:
ktpass /out <filename>.keytab /mapuser <kerberos_account>@<REALM> /princ HTTP/<kerberos_account>@<REALM> /pass <password>

Note: The realm must be in all uppercase.

The following is an example:

ktpass /mapuser sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /princ HTTP/sentry1_eas_kcd@TEXAS.IRONMOBILE.COM /pass mypassword1

The returned information for the above example looks like this:

Targeting domain controller: dc_01.texas.ironmobile.com
Using legacy password setting method
Successfully mapped HTTP/sentry1_eas_kcd to sentry1_eas_kcd.
WARNING: pType and account type do not match. This might cause problems.
Key created.

Note: the warning can be ignored.

Repeat this procedure to map each Sentry / Sentry Service Account name to the servicePrincipalName if multiple Sentry service accounts where created.

Note: If the password for the service account changes, you must remap the service account to
the ServicePrincipalName using the new password before the current service token expires.  Failure to re-map using the new password before the service token expires will result in the KDC failing to renew the token which will prevent users from receiving email.

Configure Constrained Delegation For Sentry Service Accounts

Now the Sentry service account is mapped to the servicePrincipalName, constrained delegation needs to be configured on properties dialog windows for each of the configured service accounts.  The following steps can be used to accomplish this configuration:

  1. Enable Delegation
  2. Configure Allowed Authentication Protocols for the CAS
  3. Select Services

Enable Delegation

To enable delegation:

  1. From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.  A browser appears that displays the Active Directory domains.
  2. Expand the realm
  3. Click Users
  4. Select the Kerberos user account that you created in “Create a Kerberos Service Account on the KDC For Each Sentry ” on page 4
  5. Right-click the account and select Properties
  6. Select the Delegation tab
  7. Select Trust This User For Delegation To Specified Services Only
  8. Select Use Any Authentication Protocol

kerberos-properties-dialog

Configure Allowed Authentication Protocols for the CAS

To configure the allowed authentication protocols for the Client Access Server (CAS):

  1. In the Delegation tab the Properties dialog for the service account, click Add
  2. Click Users or Computers
  3. In the Select Users or Computers dialog that appears, type the name (or the first few characters) of the CAS
    usersandcomputersselection
  4. Click Check Names, the names of the CAS servers that match the string entered appear in the box
  5. Select the CAS to configure the authentication protocols
  6. Click OK

The Add Services dialog appears and displays a list of all services available on the selected CAS
Servers.

addservicesdialog

Select Services

Multiple service types can be selected, but http must be selected at minimum for this functionality.

To select services to use for authentication:

  1. Scroll down to the http service type and select it
  2. Use Ctrl-click to select additional services types
  3. Click OK, the service types selected are added to the Delegation tab
  4. Click OK in the Properties dialog

If multiple CAS servers are in use, add the http service for each of the servers using the steps above.

Verify the Group Policy Values

Verify the group policy settings for Kerberos are set to the default values. MobileIron recommends that the default values are used.

To verify the group policy values for Kerberos:

  1. Log in to the KDC server as an administrator
  2. From Start > All Programs, select Administrative Tools > Group Policy Management
  3. Expand the domain and select Group Policy Objects
  4. Right-click Default Domain Policy and select Edit, the Group Policy Management Editor appears.
  5. Expand Computer Configuration and select Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy.
    defaultkerberosgpsettings
    The highlighted values are the default Kerberos values.

    Edit a policy setting:

  1. Double-click the policy
  2. Edit the value in the pop-up that appears
  3. Click OK

Enable the Kerberos Protocol on the Exchange Server

Enable the Kerberos protocol on the Exchange server so that Sentry can use Kerberos to
authenticate with Exchange

Steps to enable Kerberos authentication in IIS:

  1. Log in to your Exchange server as an administrator
  2. From the Start menu, select Administrative Tools > Internet Information Services (IIS) Manager
  3. Expand the Exchange CAS that is configured for the Sentry
  4. Navigate to Sites > Default Web Site > Microsoft-Server-ActiveSync
  5. Double-click Authentication in the middle pane, the Authentication page opens in the middle pane
    iis-authentication-dialog
  6. Select Windows Authentication in the middle pane
  7. Select Providers in the right pane, the Providers dialog displays
    providers-dialog
  8. If Negotiate:Kerberos is not already in the Enabled Providers list, select it from the Available Providers drop-down list and click Add, Negotiate:Kerberos moves from Available Providers to Enabled Providers
  9. Click OK
  10. Ensure that Windows Authentication and Basic Authorization are enabled in the middle pane

iis-authentication-types

If one or both of them are not enabled, select the disabled authentication type and click Enable
in the Actions pane on the right.  Check that all other authentication types are disabled.  The Exchange server and the Active Directory server are now both set up for Kerberos authentication.

Note: Basic Authentication can be disabled to prevent non-certificate-based authentication.

Set Up SCEP for Kerberos Authentication

Configure SCEP to work with Kerberos constrained delegation. It is important to configure the SCEP profile with the following:

  • enable the proxy
  • set the Subject Alternative Name Type to NT Principal Name
  • set the Subject Alternative Name Type Value to $USER_UPN$

To set up SCEP for Kerberos authentication:

  1. Log in to the VSP Smartphone Manager
  2. If you are setting up a new SCEP profile, select Apps & Files | App Settings | Add New | SCEP
    createmiscepprofile
    If you are updating an existing SCEP profile, select the profile name and click Edit in the right panel.
  3. Configure the SCEP settings by filling out the form.  For details on the configuration options, please look here.

4. Click Save.

Note: If the SCEP entry is not valid, you will be prompted to correct it. Partial and invalid entries cannot be saved.

Set Up the Exchange Profile for Kerberos Authentication

Configure the Exchange profile for each of your Exchange servers that are using Kerberos authen- tication. Configure the Password field to pass the $NULL$ variable. Sentry is using identity certifi- cates for authentication so a password is not required.

To set up the Exchange profile for Kerberos authentication:

  1. Log in to the Smartphone Manager.
  2. If you are setting up a new Exchange profile, select Apps & Files | App Settings | Add New | Exchange.
  3. Configure the Exchange profile by filling out the form with the required values.  Explanations of each setting can be found here.  The 2 important settings for Kerberos authentication are going to be ActiveSync Password which should have a value of $NULL$ and Identity Certificate which should have the certificate of the user.
  4. Click Save once everything has been set correctly

Configure Device Authentication

Configuration of device authentication for Standalone Sentry takes place on the associated VSP.

To configure authentication:

  1. Obtain the certificates required for your implementation, this will be the certificate authority certificate
  2. In Smartphone Manager, select Settings | Sentry
    mobileiron-edit-sentry-configuration
  3. Click the edit icon for the existing Standalone Sentry
    mobileiron-deviceauthenticationtype
  4. In the Device Authentication list, select Identity Certificate (Kerberos).
    The following figure shows the form for Kerberos authentication.
    mobileiron-kerberosconfig
  5. Click Upload Certificate
  6. Select the trusted root certificate chain received from the Kerberos administrator
  7. Click Upload
  8. If the certificates presented by the device against the Certificate
    Revocation List (CRL) published by the CA are going to be validated, then the Check Certificate Revocation List (CRL) checkbox should be selected.
    Notes: Only HTTP- and HTTPS-based CRLs are supported. Some CAs create LDAP-based CRLs by default that will not work with Sentry.
    For CRL validation to work, Sentry requires network connectivity to the CRL Distribution Point
    (CDP), usually the CA that issued the certificate, through an HTTP or HTTPS port.
  9. Use the Subject Alternate Name Type list to select the field in the client certificate that will be
    used to identify the user for Kerberos Constrained Delegation.
    Note: The Type is the same type that you specified when generating the client certificate. This type is often the NT Principal Name.
  10. Use the Value list to select the value used in the Subject Alternate Name field.
    Usually, the User UPN (user principal name) is used to identify the user.
  11. If a Kerberos-generated keytab file is used:
    a. Select the Use Keytab File checkbox
    b. Click the Upload File button that displays
    c. Select the keytab file
    d. Click Upload
    The keytab file provides the required Kerberos authentication information. For information
    about generating a keytab, see Map the Sentry Service Account and Create a Keytab.
    e. Optionally configure one or more Key Distribution Centers (see step 12).
    Note: If no KDC is specified, the system auto-detects the KDC.
  12. If no keytab file was uploaded, the Kerberos configuration fields will need to be completed manually. Use the following guidelines:
    • Realm  Enter the Kerberos administrative domain. The realm is usually the company domain name, in all uppercase characters.
    • Sentry Service Principal  The service principal for the Sentry service account, preceded by HTTP/. For example, if the user name of the service account is sentry1_eas_kcd, the service principal would be HTTP/sentry1_eas_kcd.
    • Password  Password for the Sentry service account
    • Key Distribution Center (optional)  The network service that supplies session tickets and temporary session keys. This is generally the Active Directory domain controller hostname.
  13. Configure the ActiveSync Server SPNs:
    • If you used the fully-qualified domain name of the ActiveSync server as the basis for the Service Principal Name of the server in the ActiveSync Server(s) field above, then select Derive SPN From FQDN Of ActiveSync Server.
    • If you configured the IP address or alternate DNS name of the ActiveSync server in the ActiveSync Server(s) field above, then deselect Derive SPN From FQDN Of ActiveSync Server.  Enter the SPNs for each of your ActiveSync servers, separated by semicolons, in the field that appears when this option is deselected. Typically, SPNs are in the form: http/<FQDN>.  For example, http/CAS.ironmobile.com.
      Note that the SPN is case-sensitive. The name of the CAS node that uses Kerberos Constrained Delegation (KCD) must exactly match the name of the node.
    • To view the CAS node:
      • Log on to the Active Directory server as an Administrator.
      • From Start > All Programs, select Administrative Tools > Active Directory Users and Computers.
      • Navigate to the Computers folder for the Kerberos realm (Kerberos refers to a domain as a realm).
      • Note the exact hostname of the CAS.

    mobileiron-cas-server

  14. Click Save

Set up Kerberos Notifications

The VSP can send notifications to one or more email addresses in the following
scenarios:

  • The Kerberos service account is locked
  • The Kerberos service account password is about to expire
  • The Kerberos service account password has expired

Email notifications are sent to the specified email addresses seven, five, two, and one days before the Kerberos service account password expires. For a locked or unavailable Kerberos service account, one notification is sent after you configure Sentry and save the configuration and the VSP detects the unavailable status of the account.
To set up notifications for Kerberos:

  1. In Smartphone Manager, select Settings | Sentry
    sentryalertconfiguration
  2. Click Preferences
    sentrypreferences
  3. Enter the email address(es), separated by commas, to send the notifications.

Validate the Kerberos Configuration

Verify that the Kerberos configuration is valid by viewing information in the Sentry log in VSP.

To validate the Kerberos configuration:

  1. Log in to System Manager on the VSP
  2. Select the Troubleshooting tab
    At the bottom of the Logs page, the associated Sentries appear in the Remote Logs section.
    sentrylogs
  3. Click the View Logs link for the Sentry to be checked
    A dialog appears that shows the Sentry log
  4. Look for the following string in the Sentry log:
    Informational only: Successfully Received Sentry Service Ticket from KDC

    Although this message appears as a warning in the log, it just provides verification that Sentry
    has received the Kerberos service ticket.

  5. Repeat steps 3 and 4 for additional Sentries.

Debugging Kerberos Certificate Issues

Kerberos certificates aren’t authenticating.

Authentication is failing when:

  • errors like the ones below are present in the sentry.log file
  • Users aren’t receiving email

The logs will show error messages that can indicate possible causes.

ERR_BAD_OPTION (error code 13)

This error code is very generic and requires you to look at the e-data in the packet trace (sentry.log?).
Use the following resource to map the error code with the issue:
http://www.monitorware.com/common/en/securityreference/kerberos-failures.php
Once you have mapped the error code to the issue, look up the issue using the following resource
for an explanation of the issue:
http://docs.oracle.com/cd/E23823_01/html/816-4557/trouble-2.html

NT_STATUS_UNMATCH

The edata (NT_STATUS_UNMATCH) error means that the Exchange server name is incorrect.
Check the Sentry configuration on the VSP to see if the Exchange host name is the same as the
hostname configured in Active Directory.

KerberosProtocolTransitionAndSPNEGO:303

Error while getting client service ticket com.dstc.security.kerberos.KerberosException: No keytab entry for decrypting data encrypted with key type 23 and kvno 3.

A warning also appears on the KDC:

“The currently selected KDC certificate was once valid, but now is invalid and no suitable replacementwas found. Smartcard logon may not function correctly if this problem is not remedied. Havethe system administrator check on the state of the domain’s public key infrastructure. The chainstatus is in the error data.”

What this means is that after the keytab was generated, the key on the KDC was changed (could
be that the password for the Sentry’s service account was changed on the AD after generating the
keytab). So, the Sentry is no longer able to decrypt the KDC packets and the Kerberos tokens that
Sentry caches can no longer be renewed. The traffic will continue to flow to the client until the client
Kerberos token expires.

To fix this issue, regenerate the keytab on the KDC and upload the new keytab to the VSP.

 

Configuring Certificates for QNAP NAS

Goal

The ability to set and configure SSL certificates that don’t display warnings to visitors is an important, but sometime frustrating process.  This guide will help anyone trying to create and apply a certificate to a QNAP NAS device.  I welcome and appreciate comments that provide issues that have been encountered with this process.  Being familiar with certificates in general, I may have missed some of the common issues encountered when attempting to apply SSL certificates.

Background / Additional Information

A couple of notes about this process.

While self-signed SSL certificates can be generated locally, it defeats the purpose of changing or applying new certificates as visitors will more than likely not be able to verify the validity of the certificate.  This guide is for generating a csr to provide to a 3rd party certificate authority like StartSSL.

Following the guide to generate certificates for Linux Apache web servers found here will be very important as this guide doesn’t detail the creation of the private key, certificate signing request, or submission of the csr to the certificate authority to generate the final certificate.  It also doesn’t cover converting the returned certificate file from cer format to pem format.  This process can be found here.

It should also be noted that some understanding of certificates and how they work is required to complete this process.

Resolution

To generate a csr file to be submitted to a certificate authority, verify that openssl is installed and if it is not, download and install it.  The following commands when run on the QNAP NAS will install openssl.

ipkg update
ipkg install openssl

Once openssl has been successfully installed, the process for generating a certificate signing request (csr) and submitting it to a certificate authority is very similar to the process on a Linux server running Apache.  For details on this process, I have created a document previously on this topic found here.  The commands for generating the csr, and converting the certificate file from cer to pem are identical.  The only difference is the application of the certificate.  The QNAP provides a user friendly web interface that is used to supply the private key and pem certificate file.  These are text boxes and require the private key and certificate file to be pasted into them and then applied.

A quick note, when issuing the openssl command, you may receive a warning message like the following: “Can’t open config file:  /usr/local/openssl.cnf”.  This indicates that the system either can’t find the file, or it is not able to access the file.  Determine which is the case and if it not in the specified path, perform a search to determine the location and copy it to the correct location, or check the permissions of the file and update as necessary.  A file may be found named openssl.cnf.example.  This file can be used by renaming it (I recommend copying it to the new name so you retain the example file) and modifying as needed.

While it might be assumed that applying your own certificate to a QNAP NAS might be a difficult process, if you have any experience with applying certificates, it should be no problem at all.

Troubleshooting

No troubleshooting steps have been defined at this point.

Exchange 2010 and Single Name Certificates

Goal / Scope

The purpose of this article is to provide a method for leveraging a single name certificate with Exchange 2010 without getting errors and warnings and potentially having some services fail altogether.  Please NOTE:  It is Microsoft recommended best practice to use a SAN (Subject Alternative Name) certificate with Exchange.  However, if for some reason this is not an option, maybe due to cost, or wanting to leverage an existing certificate, the process below will allow a single name certificate to be used with Exchange.

Notes:
Again, this is likely not a Microsoft supported configuration. While successfully rolled it out in small environments with success, if a SAN certificate can be purchased and used, that is the best case.

Background

Below are some of the things that need to be in place for this configuration to be successful.

Prerequisites

  • An external DNS provider that supports SRV records. You’ll need to insert an SRV record of _autodiscover._tcp.domain.com in DNS for this to work
  • Outlook 2007 with the update rollup released June 27, 2007 (Discussed in this Microsoft KB article) to provide support for Exchange Autodiscover via SRV lookup
  • An SSL certificate for mail.domain.com

Methodology / Process Steps

In the examples shown below, [domain.com] is the domain name, [mail.domain.com] is the URL being set for all services and EXCHANGE is the NetBIOS name of the Exchange server.

  1. Point external DNS for mail.domain.com to the external IP address of the Exchange server.
  2. Create the SRV record _autodiscover._tcp.domain.com with content of [mail.domain.com] on port 443. Your DNS provider might also have you enter it like this:
    Service: _autodiscover
    Protocol: _tcp
    Port Number: 443
    Host: [mail.domain.com]
  3. Point internal DNS for [mail.domain.com] to the internal IP address of the Exchange server.
  4. Set the Internal URLs.

    Note:  These examples can be copied and pasted into a text editor.  Simply replacing [mail.domain.com] with the correct FQDN of the Exchange server and paste the new commands directly into a PowerShell window on the Exchange 2010 server.

    Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –InternalUrl "https://mail.domain.com/Autodiscover/Autodiscover.xml"
    Get-ClientAccessServer | Set-ClientAccessServer –AutodiscoverServiceInternalUri "https://mail.domain.com/Autodiscover/Autodiscover.xml"
    Get-WebservicesVirtualDirectory | Set-WebservicesVirtualDirectory –InternalUrl "https://mail.domain.com/Ews/Exchange.asmx"
    Get-OabVirtualDirectory | Set-OabVirtualDirectory –InternalUrl "https://mail.domain.com/Oab"
    Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –InternalUrl "https://mail.domain.com/Owa"
    Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –InternalUrl "https://mail.domain.com/Ecp"
    Get-ActiveSyncVirtualDirectory -Server $CASserver | Set-ActiveSyncVirtualDirectory -InternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"
  5. Set the External URLs.

    Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –ExternalUrl "https://mail.domain.com/Autodiscover/Autodiscover.xml"
    Get-webservicesVirtualDirectory | Set-webservicesVirtualDirectory –ExternalUrl "https://mail.domain.com/Ews/Exchange.asmx"
    Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalUrl "https://mail.domain.com/Oab"
    Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –ExternalUrl "https://mail.domain.com/Owa"
    Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –ExternalUrl "https://mail.domain.com/Ecp"
    Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"
  6. Verify everything was set correctly
    Get-AutodiscoverVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    
    Get-webservicesVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    
    Get-OabVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    
    Get-OwaVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    
    Get-EcpVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    
    Get-ActiveSyncVirtualDirectory | ft Identity,InternalURL,ExternalUrl
  7. Verify everything is working by using the Exchange Remote Connectivity Analyzer located at https://www.testexchangeconnectivity.com

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.

Problem: | Certificate errors are still present, services fail to function properly like OAB for example

Solution: | Use the Outlook Connectivity Test (found by pressing Ctrl on the keyboard and right clicking the Outlook icon with the mouse.  One of the options will be “Test E-mail AutoConfiguration …”.  After supplying username and password information, it attempt an autodiscover email configuration and supply results of the test in the window.  “Connection Status” is also a useful utility and can be opened using the same method.  This will display the connection status of the Outlook client.

References

The PowerShell code used in this guide was taken directly from this article:

http://blog.cohesivelogic.com/exchange-2010-single-name-ssl-certificates

Extracting Certificate and Private Key Files from a .pfx File

Purpose

There may be scenarios when a certificate file and private key file are required, but only a single .pfx file is available.  A Microsoft based Windows platform doesn’t provide a way to complete this process.

It is still possible to obtain the required files.  By exporting the certificate from the Windows Certificate Store using the Windows MMC into a single .pfx file, separate certificate and private key files can be created from this .pfx file.  Below is the process beginning once the .pfx file has been obtained.

Procedure

  • The first step is to copy the exported file (e.g. certname.pfx)  to a system where OpenSSL is installed.
    NOTE: *.pfx files are in PKCS#12 format and include both the certificate and the private key.
  • The following command will export the private key:
openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes

 

  • The next command will export the certificate:
openssl pkcs12 -in certname.pfx -nokeys -out cert.pem

 

  • Finally, the last command will remove the passphrase from the private key: (if needed)
openssl rsa -in key.pem -out server.key

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.

Problem: |

Solution: |

Problem: |

Solution: |

References

Open SSL pkcs#12 Commands