Export (0) Print
Expand All

BizTalk Server 2004 Technical Guide for Certificate Management

Laura Machado de Wright

Microsoft Corporation

May 2005

Applies to: BizTalk Server 2004

Summary: This paper provides detailed information about how to configure your BizTalk Server environment to use certificates for encryption, signing, and party resolution. (66 printed pages)

Microsoft® BizTalk® Server 2004 relies heavily on the security provided by certificates. By using certificates for encryption and digital signatures, BizTalk Server can send and receive data that can be trusted. The BizTalk Server 2004 Technical Guide for Certificate Management provides detailed information about how to configure your BizTalk Server environment to use certificates for encryption, signing, and party resolution. It also provides a sample application to help you automate the installation of certificates in the certificate stores that BizTalk Server uses when processing messages.

By using certificates, companies can conduct business electronically with authentic and private message exchanges. Authenticity involves validating the digital signatures or identities of those who send messages, while privacy involves encrypting confidential information to prevent tampering and unintended disclosure. Companies can use separate certificates for digital signatures and encryption.

This document assumes that you are familiar with public key infrastructure (PKI), certificates, and certification authorities. For information about cryptography and certificates on MSDN®, the Microsoft Developer Network, see Cryptography.

You can configure your Microsoft® BizTalk® Server 2004 environment to use certificates for sending and receiving signed and encrypted messages. By using certificates for encryption and digital signatures, BizTalk Server can:

  • Send and receive data that can be trusted.
  • Make sure that the data it processes is secure.
  • Make sure that authorized parties receive its messages.
  • Make sure that it receives messages from authorized parties.

This section provides information about how to configure BizTalk Server 2004 pipelines, receive locations, ports, and the BizTalk Server environment to receive and send encrypted and signed messages, and how to use the signing certificates for party resolution.

Storing Certificates for BizTalk Server 2004

Depending on the purpose of a certificate (signing messages, verifying signatures, decrypting messages, encrypting messages, or party resolution), it must be installed in a specific certificate store. This section describes which certificates have to be stored in each certificate store to be available to the BizTalk Server processes and services.

Windows Certificate Stores That BizTalk Server Uses

BizTalk Server uses two Windows® certificate stores - the Other People certificate store (in the Local Computer folder) for public keys, and the Personal certificate store (in the Current User folder) for the service account of each host instance for private keys.

  • Other People certificate store. Public key certificates, as their name implies, are public and accessible by anyone with access to the computer on which they are stored. BizTalk Server retrieves from this store the public key certificates to encrypt messages and to verify the digital signatures for incoming messages. All users can read and use the certificates in this store.
    The following figure shows the Other People certificate store that BizTalk Server uses for public key certificates.
    Figure 1 Other People certificate store
    <No Change>

  • Personal certificate store. BizTalk Server uses private key certificates to decrypt incoming messages and sign outbound messages. Every Windows account enabled to log on interactively on a computer has a personal certificate store that only that account can access. BizTalk Server uses the personal certificate store for the service account of each host instance to access the private key certificates to which each service account has access. The private key certificates must be stored in the Personal certificate store for the service account for each host instance on each computer that has a running host instance that requires the certificate for decryption or for signing outbound messages.
    ms865024.note(en-US,BTS.10).gifNote
    The personal certificate store is also named the MY certificate store when it is used for programmatic operations, such as scripting the importing and exporting of certificates.

    The following figure shows the Personal certificate store that BizTalk Server uses for private key certificates.
    Figure 2 Personal certificate store
    <No Change>

For more information about the certificate stores and the Certificate snap-in for the Microsoft Management Console (MMC), search for "Certificate console" in Windows XP, Windows Server™ 2003, or Windows 2000 Server Help.

Certificates That You Need in Each Store

The following table describes the certificates that you must install in each Windows certificate store.

Table 1 Certificates for each Windows certificate store

Certificate purpose Certificate type Certificate store

Signing

Own private key

Personal store for each service account of a host instance that has a send pipeline with a MIME/SMIME Encoder pipeline component configured to sign messages (Add Signing Cert To Message property set to True).

Verifying signature

Partner's public key

Other People store on each computer that has a host instance that has a receive pipeline with a MIME/SMIME Decoder pipeline component.

Decrypting

Own private key

Personal store for each service account of a host instance that has a receive pipeline with a MIME/SMIME Decoder pipeline component.

Encrypting

Partner's public key

Other People store on each computer that has a host instance that has a send pipeline with a MIME/SMIME Encoder pipeline component configured to encrypt messages (Enable encryption property set to True).

Party resolution

Partner's public key

Other People store on the administration computer from which you are configuring party resolution.

The following figure shows what certificates you will need in each certificate store on a BizTalk Server dedicated to receiving messages.

Figure 3 Certificates required in a BizTalk Server dedicated to receiving messages

<No Change>

The following figure shows what certificates you will need in each certificate store on a BizTalk Server dedicated to sending messages.

Figure 4 Certificates required in a BizTalk Server dedicated to sending messages

<No Change>

For more information about certificates and about managing certificates in the Certificate snap-in, search for "Certificates" in Windows XP, Windows Server 2003, or Windows 2000 Server Help.

BizTalk Server 2004 supports public key encryption of outbound messages and decryption of inbound messages based on S/MIME. BizTalk Server uses S/MIME version 3 for encryption of outbound messages, and S/MIME versions 2 and 3 for decryption of inbound messages.

Receiving Encrypted Messages

The following figure shows the message flow when BizTalk Server receives an encrypted message.

Figure 5 Message Flow when receiving an encrypted message

The message flow when BizTalk Server receives an encrypted message is as follows:

  1. A partner sends a message to BizTalk Server. The partner encrypts the message with the BizTalk Server public key.
  2. The appropriate BizTalk Server receive handler receives the message.
  3. During the receive pipeline execution, the MIME/SMIME Decoder pipeline component decrypts the message by using the BizTalk Server private key.
  4. Additional processing occurs.

Sending Encrypted Messages

The following figure shows the message flow when BizTalk Server sends an encrypted message.

Figure 6 Message Flow when sending an encrypted message

<No Change>

The message flow when BizTalk Server sends an encrypted message to a partner is as follows:

  1. The appropriate BizTalk Server send handler sends a message to the partner.
  2. During the send pipeline execution, the MIME/SMIME Encoder pipeline component encrypts the message by using the partner's public key.
  3. The partner receives the message from BizTalk Server. The partner uses its private key to decrypt the message.

This section describes the steps that you have to follow to configure a BizTalk Server environment to receive and send encrypted messages.

At a high level, the steps are:

  • Install the certificate keys in the certificate stores.
  • Configure the pipelines to receive and send encrypted messages.

Installing the Certificate Keys in the Certificate Stores

The following procedure lists the high-level steps that you have to follow to install the certificates for receiving encrypted messages in the certificate stores.

To install the decryption certificates
  1. An administrator in your organization requests a private-public key pair for encryption from the certification authority (CA) for BizTalk Server to use.

  2. The administrator sends Partner A the public key for encryption. For recommendations on how to send public keys to your partners, see Certificate Management Best Practices.

  3. In BizTalk Server, log on as the service account for the host instance running the handler that will receive messages from Partner A. Install the BizTalk Server private key certificate for decrypting messages in the personal store for the service account. The following figure shows the certificate store where you install the certificate.

    <No Change>
  4. In Partner A, install the BizTalk Server public key certificate for encrypting messages sent to Partner A in the appropriate store. (If Partner A is using Windows 2000 Server or Windows Server 2003, install the public key in the Other People store.)

The following procedure lists the high-level steps that you have to follow to install the certificates for sending encrypted messages in the certificate stores.

To install the encryption certificates
  1. Partner A requests a private-public key pair for encryption from the CA.

  2. Partner A installs the private key certificate for decrypting the messages in the appropriate store. (If Partner A is using Windows 2000 Server or Windows Server 2003, install the private key in the personal certificate store.)

  3. Partner A sends you its public key for encrypting messages sent to Partner A.

  4. In BizTalk Server, log on to the server that has a host instance running a handler that will send messages to Partner A. Install the Partner A public key certificate for encrypting messages sent to Partner A in the Other People store. The following figure shows the certificate store where you install the certificate.

    <No Change>

Configuring BizTalk Server to Receive Encrypted Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to receive encrypted messages.

ms865024.note(en-US,BTS.10).gifNote
The MIME/SMIME Decoder pipeline component performs both decryption and digital signature validation (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to receive encrypted and signed messages, you can use the same receive pipeline. In other words, you do not have to create separate pipelines for decryption and digital signature validation.

ms865024.note(en-US,BTS.10).gifNote
You can use one certificate for both signing and decryption operations, or you can use one certificate for each function.

To configure BizTalk Server to receive encrypted messages
  1. Create a new receive pipeline:

    1. In Solution Explorer, select the project in which you want to create the pipeline.
    2. On the File menu, click Add New Item.
    3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
    4. In the Name field, type a name for the pipeline.
    5. Click Open.
      The new pipeline appears in Solution Explorer.
  2. Drag the MIME/SMIME Decoder pipeline component into the Decode stage of a receive pipeline.

    <No Change>
  3. Configure the MIME/SMIME Decoder pipeline component properties in the Properties window. For more information about the MIME/SMIME decoder, see "Configuring the MIME/SMIME Decoder Pipeline Component" in BizTalk Server 2004 Help.

  4. Build and deploy the receive pipeline.

  5. In BizTalk Explorer, create a new receive port.

  6. Create a new receive location. In the Receive Pipeline drop-down list, select the pipeline you created in step 1. In the Receive Handler drop-down list, select the BizTalk Host where the receive location will run.

  7. Configure the host running the receive pipeline with the decryption certificate:

    1. Open BizTalk Server Administration.
    2. Expand the Microsoft BizTalk Server 2004 (local) node, and then double-click Hosts.
    3. Right-click the host where the receive location you created in step 6 will run, and select Properties.
    4. In the <Host Name> Properties dialog box, on the Certificate tab, type the thumbprint value for the decryption certificate that BizTalk Server will use to decrypt messages it receives through the receive location.

Configuring BizTalk Server to Send Encrypted Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to send encrypted messages.

ms865024.note(en-US,BTS.10).gifNote
The MIME/SMIME Encoder pipeline component performs both encryption and digital signing (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to send encrypted and signed messages, you can use the same send pipeline. In other words, you do not have to create separate pipelines for encryption and digital signing.

To configure BizTalk Server to send encrypted messages
  1. Create a new send pipeline:

    1. In Solution Explorer, select the project in which you want to create the pipeline.
    2. On the File menu, click Add New Item.
    3. In the Add New Item dialog box, select the Send Pipeline template by clicking it once.
    4. In the Name field, type a name for the pipeline.
    5. Click Open.
      The new pipeline appears in Solution Explorer.
  2. Drag the MIME/SMIME Encoder pipeline component into the Encode stage of a receive pipeline.

    <No Change>
  3. In the Properties window, configure the MIME/SMIME Encoder pipeline component Enable encryption property to True. For more information about the MIME/SMIME encoder, see "Configuring the MIME/SMIME Encoder Pipeline Component" in BizTalk Server 2004 Help.

  4. Build and deploy the send pipeline.

  5. In BizTalk Explorer, create a new send port.

  6. In General Properties, in the Send Pipeline drop-down list, select the pipeline you created in step 1.

  7. In the Certificate Name drop-down list, select the public key encryption certificate that BizTalk Server will use to encrypt messages sent to the partner.

BizTalk Server supports using digital signature certificates both to sign outbound messages and to verify the signature of inbound messages. BizTalk Server uses S/MIME versions 2 and 3 to sign outbound messages and to validate the signature of inbound messages. The signing certificate supported by BizTalk Server is x.509 version 3.

Using Digital Signature Certificates with Inbound Messages

The following figure shows the message flow when BizTalk Server receives a digitally signed message.

Figure 7 Message Flow when receiving a digitally signed message

The message flow when BizTalk Server receives a digitally signed message is as follows:

  1. A partner sends a message to BizTalk Server. The partner signs the message with its private key certificate.
  2. The appropriate BizTalk Server receive handler receives the message.
  3. During the execution of the receive pipeline, the MIME/SMIME Decoder pipeline component verifies the digital signature by using the partner's public key.
  4. Additional processing occurs.

Using Digital Signature Certificates with Outbound Messages

The following figure shows the message flow when BizTalk Server sends a digitally signed message.

Figure 8 Message Flow when sending a digitally signed message

<No Change>

The message flow when BizTalk Server sends a digitally signed message to a partner is as follows:

  1. The appropriate BizTalk Server send handler sends a message to the partner.
  2. During the execution of the send pipeline, the MIME/SMIME Encoder pipeline component signs the message by using the BizTalk Server private key.
  3. The partner receives the message from BizTalk Server. The partner uses the BizTalk Server public key to verify the digital signature.

This section describes the steps that you have to follow to configure a BizTalk Server environment to receive and send signed messages.

At a high level, the steps are:

  • Install the certificate keys in the certificate stores.
  • Configure the pipelines to receive and send signed messages.
  • Specify the signing certificate in the BizTalk Administration console.

Installing the Certificate Keys in the Certificate Stores

The following procedure lists the steps that you have to follow to install the certificates for receiving signed messages in the certificate stores.

To install the certificates to receive signed messages
  1. Partner A requests a private-public key pair for digital signatures from the certification authority (CA).

  2. Partner A sends you its public key for digital signatures.

  3. In BizTalk Server, log on to the server that has a host instance running a handler that will receive messages from Partner A. Install the Partner A public key certificate to verify their signature in the Other People store. The following figure shows the certificate store where you install the certificate.

    <No Change>
  4. In Partner A, install the Partner A private key certificate for signing messages in the appropriate store. (If Partner A is using Windows 2000 Server or Windows Server 2003, install the private key in the personal store for the account that will sign messages sent to BizTalk Server.)

The following procedure lists the steps that you have to follow to install the certificates for sending signed messages in the certificate stores.

To install the signing certificates for sending signed messages in the certificate stores
  1. An administrator in your organization requests a private-public key pair for digital signatures from the CA for BizTalk Server to use.

    ms865024.note(en-US,BTS.10).gifImportant
    You can only specify one signing certificate with which BizTalk Server signs all outbound messages. In other words, you cannot use different signing certificates depending on who you are sending the message to.

  2. The administrator sends Partner A (and all other partners) the public key for digital signatures. For recommendations on how to send public keys to your partners, see Certificate Management Best Practices.

  3. In BizTalk Server, log on as service account for the host instance running the handler that will send messages to Partner A. Install the BizTalk Server private key certificate for signing messages in the personal store for the service account. The following figure shows the certificate store where you install the certificate.

    <No Change>
  4. In Partner A, install the BizTalk Server public key certificate for verifying its digital signature in the appropriate store. (If Partner A is using Windows 2000 Server or Windows Server 2003, install the public key in the Other people store.)

Configuring BizTalk Server to Receive Signed Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to receive signed messages.

ms865024.note(en-US,BTS.10).gifNote
The MIME/SMIME Decoder pipeline component performs both decryption and digital signature validation (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to receive encrypted and signed messages, you can use the same receive pipeline. In other words, you do not have to create separate pipelines for decryption and digital signature validation.

To configure BizTalk Server to receive signed messages
  1. Create a new receive pipeline:

    1. In Solution Explorer, select the project in which you want to create the pipeline.
    2. On the File menu, click Add New Item.
    3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
    4. In the Name field, type a name for the pipeline.
    5. Click Open.
      The new pipeline appears in Solution Explorer.
  2. Drag the MIME/SMIME Decoder pipeline component into the Decode stage of a receive pipeline.

    <No Change>
  3. Configure the MIME/SMIME Decoder pipeline decoder properties in the Properties window. For more information about the MIME/SMIME decoder, see "Configuring the MIME/SMIME Decoder Pipeline Component" in BizTalk Server 2004 Help.

  4. Build and deploy the receive pipeline.

  5. In BizTalk Explorer, create a new receive port.

  6. Create a new receive location. In the Receive Pipeline drop-down list, select the pipeline you created in step 1.

Configuring BizTalk Server to Send Signed Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to send signed messages.

ms865024.note(en-US,BTS.10).gifNote
The MIME/SMIME Encoder pipeline component performs both encryption and digital signing (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to send encrypted and signed messages, you can use the same send pipeline. In other words, you do not have to create separate pipelines for encryption and digital signing.

ms865024.note(en-US,BTS.10).gifNote
You can use one certificate for both signing and decryption operations, or you can use one certificate for each function.

To configure BizTalk Server to send signed messages
  1. Create a new send pipeline:

    1. In Solution Explorer, select the project in which you want to create the pipeline.
    2. On the File menu, click Add New Item.
    3. In the Add New Item dialog box, select the Send Pipeline template by clicking it once.
    4. In the Name field, type a name for the pipeline.
    5. Click Open.
      The new pipeline appears in Solution Explorer.
  2. Drag the MIME/SMIME Encoder pipeline component into the Encode stage of a receive pipeline. For more information about the MIME/SMIME encoder, see "Configuring the MIME/SMIME Encoder Pipeline Component" in BizTalk Server 2004 Help.

    <No Change>
  3. In the Properties window, configure the MIME/SMIME Encoder pipeline component Signature type property to ClearSign or BlobSign properties.

    ms865024.note(en-US,BTS.10).gifImportant
    If you are also using encryption, you can only select BlobSign.

  4. Build and deploy the send pipeline.

  5. In BizTalk Explorer, create a new send port.

  6. Expand the Send node, and then the General node. In the Send Pipeline drop-down list, select the pipeline you created in step 1.

Specifying the Signing Certificate in the BizTalk Administration Console

The following procedure lists the steps that you have to follow to identify the signing certificate that BizTalk Server will use to sign all messages that are processed by a send pipeline that contains a MIME/SMIME encoder component that is configured to send signed messages.

To specify the signing certificate in the BizTalk Administration console
  1. Open BizTalk Server Administration.

  2. Right-click the Microsoft BizTalk Server 2004 (local) node, and then click Properties.

  3. In the Microsoft BizTalk Server 2004 (local) Properties dialog box, on the General tab, in the Thumbprint box, type the thumbprint of the private key for the signing certificate. The certificate thumbprint has the format HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH, where H is a hexadecimal digit.

A party is an entity outside BizTalk Server that interacts with an orchestration. When you use BizTalk Explorer (either the user interface or the object model) to configure a party, you can choose to resolve the party by using its digital signature. In other words, when BizTalk Server receives a message, it uses the public key certificate to determine who sent the message, and to resolve the sender to a known party in the BizTalk Server environment.

Using Digital Signatures for Party Resolution

The following figure shows the message flow when BizTalk Server receives a digitally signed message and uses the digital signature to resolve the partner identity to a party in the BizTalk Server environment. In this scenario, the partner who sends the message is resolved to Party A.

Figure 9 BizTalk Server message flow

<No Change>

The message flow when BizTalk Server uses the signing certificate to resolve the party is as follows:

  1. A partner sends a message to BizTalk Server. The partner signs the message with its private key.
  2. The appropriate BizTalk Server receive handler receives the message.
  3. During the execution of the receive pipeline, the MIME/SMIME Decoder pipeline component verifies the digital signature by using the partner's public key.
  4. During the execution of the receive pipeline party resolution component, the Partner's public key certificate is used to identify the party in the BizTalk Server system.
  5. Additional processing occurs.

This section describes the steps that you have to follow to configure a BizTalk Server environment to use certificates for party resolution.

At a high level, the steps are:

  • Install the certificate keys in the certificate stores. Because you are using the same certificate that you use for verifying the partner's signature, follow the steps in the topic Configuring BizTalk Server 2004 to Use Signing Certificates.
  • Configure the Party Resolution component in the receive pipeline.

Using Certificates for Party Resolution

The following procedure lists the steps that you have to follow to configure the Party Resolution component in a BizTalk Server receive pipeline.

ms865024.note(en-US,BTS.10).gifNote
You can also use the default XMLReceive pipeline instead of creating a new receive pipeline. The XMLReceive pipeline runs the Party Resolution component, which resolves the certificate subject to the party ID. Note that the XMLReceive pipeline has an empty Decode stage, and therefore you cannot use it for receiving encrypted messages or verifying digital signatures.

To configure BizTalk Server to use certificates for party resolution
  1. Create a new receive pipeline:

    1. In Solution Explorer, select the project in which you want to create the pipeline.
    2. On the File menu, click Add New Item.
    3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
    4. In the Name field, type a name for the pipeline.
    5. Click Open.
      The new pipeline appears in Solution Explorer.
  2. Configure the Decode stage as indicated in the procedure "To configure BizTalk Server to receive signed messages" in the topic Configuring BizTalk Server 2004 to Use Signing Certificates.

  3. Drag the Party Resolution pipeline component into the ResolveParty stage of a receive pipeline. For more information about the Party Resolution pipeline component, see "Configuring the Party Resolution Pipeline Component" in BizTalk Server 2004 Help.

  4. In the Properties window, configure the Party Resolution pipeline property Resolve party by certificate to True.

  5. Build and deploy the receive pipeline.

  6. In BizTalk Explorer, create a new party.

  7. In the Certificates properties, from the Certificate Name drop-down list, select the public key signing certificate to use to identify this party.

This section provides some recommendations and best practices for managing certificates in your Microsoft® BizTalk® Server 2004 environment.

Some best practices to consider are:

  • Do a threat model analysis of your environment to determine whether using signing or encryption certificates can help you mitigate some security threats.
  • Create a plan for receiving and sending public key certificates to and from partners. If you are not using signing certificates for party resolution, the public certificate can be attached to the message, in which case you do not have to have a copy of the certificate in your system beforehand.
  • Download the certificate revocation list (CRL) from your certification authority (CA) at set intervals. We recommend once a week.
  • As part of your service level agreement with your partner, establish guidelines for submitting public keys, notifying you when their certificates are about to expire, and notifying you when they revoke a certificate.
  • Make sure you verify the signing certificates against the certificate revocation list by configuring the Check Revocation List option in the Decode MIME/SMIME pipeline component to Yes.
  • Determine what you want to do with messages that you receive when BizTalk Server 2004 cannot validate the digital signature. Setting the Requires MSMQ authentication flag on the receive location and AuthenticationRequired (Drop messages) on the receive port to True will help prevent denial of service attacks. Remember that the AuthenticationRequired flag on the receive port requires the Party Resolution pipeline component to be configured correctly, and that the parties are defined in BizTalk Explorer. For more information about configuring the Party Resolution pipeline component, see BizTalk Message Queuing Party Resolution in BizTalk Server 2004 Help.
  • If you plan to receive MIME-encrypted messages from some partners and unencrypted messages from other partners, create separate receive locations in different hosts for encrypted and unencrypted messages. When you expect only MIME-encrypted messages, configure the Allow Non MIME Message option in the Decode MIME/SMIME pipeline component to No.
  • Make certificate management part of your partner management practices. In other words, when you add or remove a party from the BizTalk Server environment, we recommend that you also add or remove the certificates associated with that partner.
  • When you use the sample utility provided with this guide to automate the installation of certificates, configure your BizTalk Server environment, including host and host instances, before installing the certificates. This way you only have to run the sample application once. If you add new host instances, even for existing hosts, you have to rerun the sample application.
  • Before removing a host instance from a BizTalk Server, remove the certificates in the personal store of the account under which the host instance is running.

Certificate management is an important process for companies that have many partners. Depending on their particular environments and business needs, companies approach and implement certificate management in a variety of ways. This section provides examples of how a company manages their certificates to meet their needs.

Company A is a hardware manufacturer. They use BizTalk Server 2004 primarily as a middleware process automation tool to control all document flow through a variety of custom components. They run over 100,000 transactions from more than 100 trading partners and over 250,000 transactions from their back end daily. Their trading partners include companies from whom they buy materials (suppliers), companies to whom they sell products (customers), companies with whom they contract, shipping companies, and internal groups such as human resources.

Certificates

Company A uses certificates to maintain confidentiality and integrity as messages travel over the Internet through several intermediaries between the company and their partners. Company A uses both signing and encryption certificates. Their trading partners typically have one certificate for both purposes.

Company A handles certificates as follows:

  • Issuing new certificates. Company A uses an internal public key infrastructure (PKI) to create their certificates. Their trading partners must acquire certificates by a method that Company A approves to be able to use the certificates for communications with Company A.
  • Renewing certificates. Their internal PKI notifies them when a certificate is about to expire. Company A does not renew their certificates. When a certificate expires, they issue a new certificate. Trading partners notify Company A when their certificates are about to expire.
  • Revoking certificates. Company A revokes their certificates through their internal PKI. They have a business process in place for their partners to notify Company A immediately if the partner's certificate has been compromised or has to be revoked. Company A uses certificate revocation lists (CRLs) to make sure they do not use revoked certificates.
  • Making public certificates available to their partners. Company A sends and receives most of their public certificates through e-mail. Signing certificates are sometimes attached to messages, in which case they do not have to have the public certificate beforehand.

This section provides a sample Microsoft® BizTalk® Server 2004 deployment that uses certificates to send and receive encrypted messages from a partner.

The sample BizTalk Server deployment described in this section is not a secure BizTalk Server deployment. For more information about how to secure your BizTalk Server deployment, see Planning a Secure Deployment in BizTalk Server 2004 Help.

The following sections provide detailed information about the sample architecture and how to configure it. One section documents a threat model analysis performed on the sample and how you can mitigate the identified threats.

This section describes the sample architecture on which we will configure BizTalk Server 2004 to send and receive encrypted messages. It shows the network architecture diagram and describes each server in the deployment.

The deployment for the sample application includes five computers. Four of these computers would typically be server-class computers in a production environment. The last computer would typically be a workstation-class computer in a production environment. The following figure shows the network diagram for the sample deployment.

Figure 10 Network diagram for the sample deployment

<No Change>

The sample depicts a Point of Sale (PoS) application in which a salesperson from Contoso requests inventory items for the store. The salesperson uses a custom application to submit the request for items. The application submits the request to BizTalk Server 2004, where the appropriate orchestration processes the order. To illustrate the use of certificates in this architecture, the orchestration sends the order to a pipeline where it is encrypted in one BizTalk Server, and then the second BizTalk Server decrypts the order before additional processing takes place. BizTalk Server uses the order information to update the SQL Server database that contains business data. BizTalk Server does a warehouse inventory check, and then submits an encrypted acknowledgment and inventory status back to the salesperson. The salesperson decrypts the message and verifies the signature.

For more information about the data flow in this sample deployment architecture, see "Data Flow Diagram" in Collect Background Information for the Sample Deployment.

Domain Controller

This computer runs Active Directory® to control the authorization of user, group, computer, and service accounts that access information across the network in the sample deployment. This computer also runs as a certification authority using Certificate Services. Computers in the sample deployment request certificates from the certification authority.

ms865024.note(en-US,BTS.10).gifNote
For this sample deployment, the domain controller acts as the certification authority for the computers in the E-Business domain and for the client computer. Typically, a third party would act as the certification authority for your company and your partner.

SQL Server

This computer runs Microsoft SQL Server™ 2000, and contains the BizTalk Server databases and the data for the sample application.

BizTalk Server

The sample deployment for certificate management contains two computers that run BizTalk Server 2004: one for receiving messages and one for sending messages. Using two separate computers makes it easier to demonstrate how BizTalk Server 2004 manages certificates in different certificate stores.

Application Computer

This computer runs the sample application that simulates an external partner, and sends messages to the BizTalk Server computers in the sample deployment.

This sample is made up of five computers - a primary domain controller and certification authority, a computer that is running Microsoft SQL Server 2000, two computers that are running Microsoft BizTalk Server 2004, and an application computer. Each computer plays a role in the sample, and you must configure each of them correctly.

This section contains procedures for configuring the five computers that are used in the sample certificate management deployment. To configure this sample deployment, you must have sufficient knowledge in the following areas:

  • Microsoft Windows Server™ 2003
  • Active Directory
  • SQL Server
  • BizTalk Server 2004

This section describes the hardware and software prerequisites for each of the five computers in the sample deployment for certificate management in BizTalk Server 2004. The sample was created and tested using Microsoft Windows Server 2003 Standard Edition as the operating system for each computer.

Domain Controller

The recommended requirements for running the domain controller computer are:

  • 550 MHz CPU
  • 256 MB RAM
  • 2+ GB of hard disk space
  • Windows Server 2003 operating system

SQL Server

The recommended requirements for computer that is running SQL Server are:

  • 550 MHz CPU
  • 256 MB RAM
  • 4 GB of hard disk space
  • Windows Server 2003 operating system
  • Microsoft SQL Server 2000 with the latest service packs

BizTalk Server 2004

The recommended requirements for running each BizTalk Server computer are:

  • 450 MHz CPU
  • 512 MB RAM
  • 6 GB of hard disk space
  • Windows Server 2003 operating system
  • Microsoft BizTalk Server 2004 and its prerequisite software

Application Client

The recommended requirements for running the application client computer are:

  • 450 MHz CPU
  • 512 MB RAM
  • 2 GB of hard disk space
  • Windows Server 2003 operating system
  • Microsoft Message Queuing (also known as MSMQ)

This section provides guidelines for configuring the domain controller in the sample BizTalk Server 2004 deployment for certificate management. It includes guidelines for configuring Active Directory, creating domain accounts, and installing Certificate Services.

Follow these steps to configure Active Directory.

To configure the domain controller
  1. Click Start, point to All Programs, point to Administrative Tools, and then click Configure Your Server Wizard.

  2. Install Domain Controller (Active Directory).

  3. Create a domain in a new forest.

  4. Select the option to install and configure Domain Name System (DNS) on the computer.

  5. The full DNS name for the new domain is contoso.com.

  6. The domain NetBIOS name is CONTOSO.

  7. Accept the defaults for the Active Directory database.

  8. Accept the default for the sysvol folder.

  9. Choose a password for the restore mode.

  10. Complete the domain controller installation and restart the computer.

After the computer restarts and Active Directory is running, create the global domain security groups that BizTalk Server 2004 will use for the sample application. Create the following new domain groups:

  • SSO Administrators
  • SSO Affiliate Administrators
  • BizTalk Server Administrators
  • BizTalk Decrypter Host Users
  • BizTalk Server Application Host Users
  • BizTalk SQL Adapter Host Users

Follow these steps to create these groups.

To create the domain groups
  1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. In the Active Directory Users and Computers window, right-click <domainname>.com, point to New, and then click Group.

  3. In the New Object - Group dialog box, type a name for the new group (for example, SSO Administrators), accept the default name for Pre-Windows 2000 groups, select Global for the Group Scope, select Security for the Group Type, and then click OK.

  4. Repeat this procedure for each remaining domain group.

After you create the BizTalk domain groups, you must create users who are part of these groups. The following table shows the domain user names and the groups to which you add them.

Table 2 Domain user names and associated groups

Domain user name Domain name description Member of

ssoadmin

SSO Administrator

  • SSO Administrators

ssoservice

SSO Service

  • SSO Administrators

ssomaster

SSO Master Secret

  • SSO Administrators

btsadmin

BizTalk Administrator

  • BizTalk Server Administrators
  • SSO Affiliate Administrators

btsproc1

BizTalk Processing

  • BizTalk Server Application Host Users

btsrcv1

BizTalk Decrypter Adapter

  • BizTalk Decrypter Host Users

sqladapter

BizTalk SQL Adapter

  • BizTalk SQL Adapter Host Users

btsinstall

BizTalk Installation

  • Local administrators group on the BizTalk Server computer
  • Local administrators group on the computer that is running SQL Server
  • SSO Administrators

Follow these steps to create these user accounts.

To create the user accounts
  1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. In the Active Directory Users and Computers window, expand <domainname>.com, right-click Users, point to New, and then click User.

  3. In the New Object - User dialog box, type a first name for the account, type the account name (for example, ssoadmin) for the User logon name, and then click Next.

  4. In the Password box, type a password for the account, and then in the Confirm password box, type the password again.

  5. Select User cannot change password, and then click Next.

  6. Click Finish.

  7. Repeat this procedure for each remaining user account.

After you create the appropriate domain user and group accounts in Active Directory, install Certificate Services so that the domain controller can issue certificates.

Follow these steps to install certificate services on the domain controller and configure it as a certification authority.

To install certificate services
  1. Log on to the computer as a domain administrator.

  2. Click Start, point to Settings, and then click Control Panel.

  3. Double-click Add or Remove Programs and then click Add/Remove Windows Components.

  4. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.

  5. On the Windows Components Wizard, CA Types page, select Stand-alone root CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

  6. On the Public and Private Key Pair page, leave the default settings, and then click Next.

  7. On the CA Identifying Information page, in the Common name for this CA box, type CertMgmtCA, and then click Next.

  8. On the Certificate Database Settings page, leave the default settings, and then click Next.

  9. If Internet Information Services (IIS) is running, you will receive a request to stop the service before proceeding with the installation. Click OK.

  10. If prompted, type the path of the Certificate Services installation files.

This section provides guidelines for installing BizTalk Server 2004 in the sample certificate management deployment. It includes guidelines for preparing for installation and for the installation process itself.

Configuring the two BizTalk Server computers requires several steps. This section describes the following steps:

  • Preparing the computers for BizTalk Server 2004 installation
  • Installing BizTalk Server 2004 on the computers
  • Creating BizTalk Hosts
  • Deleting unnecessary adapters
  • Adding the BizTalk Message Queuing adapter

Before you install BizTalk Server 2004, you must configure the two computers to join the domain, and also configure Microsoft Distributed Transaction Coordinator (MS DTC). After you complete these preliminary steps, you are ready to configure the BizTalk Server 2004 computers.

Follow these steps to configure the BizTalk Server 2004 computers.

To prepare the computers for BizTalk Server 2004 installation
  1. Name the first BizTalk Server 2004 computer BTS-SRV. The sample certificate management deployment program assumes that this receiving computer is named BTS-SRV. If it is not, you can change the default BizTalk Server in the sample certificate management deployment program described later in this document.

  2. Add the computer to the CONTOSO domain.

  3. Add the btsinstall domain user to the local administrators group.

  4. Log off and then log on using the btsinstall domain user.

  5. Modify MS DTC on the computer:

    1. Open Administrative Tools.
    2. Open Component Services.
    3. Right-click My Computer.
    4. Click Properties.
    5. Click the MSDTC tab.
    6. Click Security Configuration.
    7. Click Security Settings.
    8. Make sure that the Network Clients check box is selected.
  6. Close the dialog box and restart the computer.

  7. Repeat steps 1 through 6 for the second BizTalk Server 2004 computer. Name this sending computer BTS2-SRV.

Follow these steps to install and configure BizTalk Server 2004.

To install BizTalk Server 2004 on the computers
  1. Log on as the BizTalk Server installation account (btsinstall).

  2. Perform a custom installation of BizTalk Server 2004. On the Custom Installation page, remove the following from the standard installation:

    • Development
    • Human Workflow Services Runtime Component
    • Base EDI Adapter
    • Rules Engine
    • Human Workflow Service Administration Tools
    • Information Worker Applications/Portal

    On the second BizTalk Server computer, remove this additional item:

    • Administration and Monitoring
  3. After you finish the BizTalk Server 2004 installation wizard, run the BizTalk Server Configuration Wizard to configure the BizTalk Server databases in SQL Server 2000.

  4. On the Configuration options page, for the first BizTalk Server installation (BTS-SRV), create a BizTalk Server group, and then click Yes to have the Single Sign-On server hold the master secret key. Click No to creating a BizTalk Host or Isolated Host Application. Click Next.

    For the second BizTalk Server 2004 installation (BTS2-SRV), join the existing group from the first BizTalk Server installation and then click No for Single Sign-On so that the master secret key only exists on the first BizTalk Server installation.

  5. On the second Configuration options page, click No to creating an Analysis database for tracking aggregation. Click No to using the Analysis Server for BAM. Click Next.

  6. On the Windows accounts page, configure the following Windows accounts for the following BizTalk Server accounts, and then click Next:

    Windows account name BizTalk Server account

    BizTalk Administrators Group

    Contoso\BizTalk Server Administrators

    SSO Administrator(s)

    Contoso\SSO Administrators

    SSO Affiliate Administrator(s)

    Contoso\SSO Affiliate Administrators

  7. On the Database configurations page, change the settings for each database so that they are created on the SQL Server that you set up earlier (SQL-Server). Click Next.

  8. On the Windows Service Configurations page, assign the Enterprise Single Sign-On Service to the Contoso\ssoservice domain user. Click Next.

  9. On the BizTalk Messaging page, click Next.

  10. On the Summary page, review the configuration options, and then click Next.

  11. Click Finish.

  12. Repeat steps 1 through 11for the second BizTalk Server computer.

After configuring the BizTalk Server 2004 computers, create BizTalk Hosts for the sample application. Follow these steps to create the following hosts:

  • BizTalkServerApplication (on BTS-SRV)
  • BizTalkEncrypter (on BTS2-SRV)
  • SQLAdapter (on BTS-SRV)
To create BizTalk Hosts
  1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

  2. Click Start, click All Programs, click Microsoft BizTalk Server 2004, and then click BizTalk Server Administration.

  3. Expand Microsoft BizTalk Server 2004 (local), right-click Hosts, click New, and then click Host.

  4. Create the BizTalkServerApplication host:

    1. Name: BizTalkServerApplication
    2. Windows Group: Contoso\BizTalk Server Application Host Users
    3. Host Type: In-Process
    4. Make sure that the Default Host in Group check box is selected.
    5. Make sure the Host tracking check box is selected.
    6. Click OK.
    7. Right-click the BizTalkServerApplication host and create a new instance of the host.
    8. Click BTS-SRV.
    9. Set the Contoso\btsproc1 account as the logon account for the host instance with the corresponding password.
    10. Click OK.
    11. If the host instance is not automatically started, in the Results pane, right-click the host instance, and then click Start.
  5. Create the BizTalkDecrypter host by using the procedure in step 4 with the following information:

    1. Name: BizTalkDecrypter
    2. Windows Group: Contoso\BizTalk Decrypter Host Users
    3. Host Type: In-Process
    4. Click OK.
    5. Right-click the BizTalkDecrypter host and create a new instance of the host.
    6. Click BTS2-SRV.
    7. Set the Contoso\btsrcv1 account as the logon account for the host instance with the corresponding password.
  6. Create the SQLAdapter host by using the procedure in step 4 with the following information:

    1. Name: SQLAdapter
    2. Windows Group: Contoso\BizTalk SQL Adapter Host Users
    3. Host Type: In-Process
    4. Click OK.
    5. Right-click the SQLAdapter host and create a new instance of the host.
    6. Click BTS-SRV.
    7. Set the Contoso\sqladapter account as the logon account for the host instance with the corresponding password.

While in the BizTalk Administration console, delete the adapters that the sample does not use. Follow these steps to delete the following adapters:

  • EDI adapter (will appear if you did not remove Base EDI Adapter from the custom installation list)
  • FTP adapter
  • HTTP adapter
  • SMTP adapter
  • SOAP adapter
To delete unnecessary adapters
  1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

  2. Open the BizTalk Administration console.

  3. Expand Adapters.

  4. Right-click the specific adapter that you want to delete, and then click Delete.

  5. In the confirmation dialog box, click Yes.

Follow these steps to add the BizTalk Message Queuing Adapter (also known as MSMQT).

To add the BizTalk Message Queuing adapter
  1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

  2. Open the BizTalk Administration console.

  3. Right-click Adapters, click New, and then click Adapter.

  4. Create a new adapter with the following information:

    • Name: MSMQT
    • Adapter: MSMQT
    • Comment: BizTalk Message Queuing Adapter
  5. In the configuration dialog box, click OK.

  6. Expand Hosts, and then click BizTalkServerApplication,

  7. In the results pane, right-click BTS-SRV, and then click Stop.

  8. In the results pane, right-click BTS-SRV, and then click Start.

Follow these steps to associate the File receive and send handlers and the SQL receive and send handlers with the correct hosts.

To configure the File and SQL Adapters
  1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

  2. Open the BizTalk Administration console.

  3. Expand Microsoft BizTalk Server 2004 (local), expand Adapters, expand FILE, and then click Receive Handlers.

  4. In the results pane, right-click the host, and then click Properties.

  5. On the <Host name> Properties page, select BizTalkDecrypter from the Host name drop-down list, and then click OK.

  6. Click Send Handlers.

  7. In the results pane, right-click the host, and then click Properties.

  8. On the <Host name> Properties page, select BizTalkDecrypter from the Host name drop-down list, and then click OK.

  9. Expand SQL, and then click Receive Handlers.

  10. In the results pane, right-click the host, and then click Properties.

  11. On the <Host name> Properties page, select SQLAdapter from the Host name drop-down list, and then click OK.

  12. Click Send Handlers.

  13. In the results pane, right-click the host, and then click Properties.

  14. On the <Host name> Properties page, select SQLAdapter from the Host name drop-down list, and then click OK.

Follow these steps on one of the BizTalk Server computers to install the files you need to configure the sample deployment.

To run the installation program for the sample deployment
  1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

  2. Run the Certificate_Management.msi installation program on one of the BizTalk Server computers.

  3. On the Welcome to the Certificate Management Technical Guide Setup Wizard page, click Next.

  4. On the License Agreement page, read the agreement. If you agree to abide by the license agreement click the I Agree option, and then click Next.

  5. Select the location where you want the sample files to be copied, and then click Next.

  6. On the Confirm Installation page, click Next.

  7. On the Installation Complete page, click Close to exit the installation program.

  8. If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder.

This section describes how to configure encryption certificates for the sample certificate management deployment. Before configuring the certificates for BizTalk Server 2004, make sure you configure the sample deployment as described in the Configuring the Sample Certificate Management Deployment topic.

This section includes the following steps:

  1. Requesting a certificate. Request an encryption certificate for the client computer from Certificate Services running on the domain controller.
  2. Exporting the private key. Export the private key from the Personal certificate store to a folder. You will need this private key later on if you use the certificate deployment utility. For more information about the certificate deployment utility, see Sample Certificate Deployment Utility.
  3. Exporting the public key. Export the public key for the encryption certificate from the Personal certificate store to a folder where the partner can access it. When you request a certificate, it contains both the public and private keys. You have to open the Personal store to export the public key to a share where you can access it. You then have to import the public key to the Local Computer\Other People store of the other computer.
  4. Importing the public key. Import the public key for encryption from the partner to the Other People certificate store.
  5. Viewing the thumbprint. When you configure the sample deployment application, you have to enter the thumbprint for the client computer certificate and for the BizTalk Server computer.

On the client application computer (APP-SRV), you must do the following:

  1. Request a certificate.
  2. Export the public key to a location accessible by the BizTalk Server computers.

On the BizTalk Server computer BTS2-SRV, you must do the following:

  1. Request a certificate.
  2. Export the public key to a location where the client computer and the other BizTalk Server computer (BTS-SRV) can access it.
  3. Import the public key for BizTalk Server to the Local Computer\Other People certificate store.

On the BizTalk Server computer BTS-SRV you must do the following:

  1. Import the public key from the client computer to this BizTalk Server computer.
  2. Import the public key from BTS2-SRV to this BizTalk Server computer.

Follow these steps on the client computer and on the second BizTalk Server computer (BTS2-SRV) to request an encryption certificate from the domain controller. The certification authority running on the domain controller issues the encryption certificate to the application client computer and to the BizTalk Server computer.

ms865024.note(en-US,BTS.10).gifNote
Make sure that Certificate Services is configured to automatically issue certificates after the request (instead of pending certificate requests). Otherwise, an administrator must manually issue the certificate. You can modify this property through the Certification Authority administrative tool.

ms865024.note(en-US,BTS.10).gifNote
This procedure assumes that you are running Windows Server 2003. If you are using a different version of Windows, the options may vary.

To request a certificate
  1. On the client computer, log on as the user who will run the application (you can use administrator or btsinstall). For BizTalk Server, log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

  2. Start Internet Explorer and connect to http://<servername>/certsrv, where <servername> is the computer name where the certification authority is running. (For this sample deployment, use the computer name of the domain controller.)

  3. On the Welcome page, click Request a certificate.

  4. On the Choose Request Type page, click advanced certificate request.

  5. On the Advanced Certificate Request page, click Create and submit a request to this CA.

  6. On the Advanced Certificate Request page, enter a friendly name for this certificate, make sure Exchange is selected for Key Usage, select Mark keys as exportable, accept the remaining default values, and then click Submit.

  7. In the Potential Scripting Violation dialog box that prompts you to confirm your certificate request, click Yes.

  8. On the Certificate Issued page, click Install this certificate.

  9. In the Potential Scripting Violation dialog box that prompts you to confirm your certificate request, click Yes.

  10. After you see the Certificate Installed page, you can close Internet Explorer.

The certificate is installed in the Personal certificate store for the account that requested the certificate.

On the client computer, you must now export the public key.

On the BizTalk Server computer, you must now export the private key.

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to export the private key from the Personal certificate store to a location that is accessible to the other BizTalk Servers that need this key.

ms865024.note(en-US,BTS.10).gifNote
You do not have to do this procedure for the client computer.

To export the private key
  1. Log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

  2. Click Start, click Run, type mmc, and then click OK.

  3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

  4. In the Add/Remove Snap-in dialog box, click Add.

  5. In the Add Standalone Snap-in dialog box, select Certificates, click Add, and then click Close.

  6. In the Add/Remove Snap-in dialog box, click OK.

  7. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates - Current User, expand Personal, and then click Certificates.

  8. In the Results pane, right-click the certificate you want to export, point to All Tasks, and then click Export to start the Certificate Export Wizard.

  9. On the Welcome to the Certificate Export Wizard page, click Next.

  10. On the Export Private Key page, click Yes, export the private key, and then click Next.

  11. On the Export File Format page, leave the defaults, and then click Next.

  12. On the Password page, type and confirm the password you want to use to help protect the private key file, and then click Next.

    ms865024.note(en-US,BTS.10).gifImportant
    If you use the certificate deployment utility to deploy private key certificates to BizTalk Server computers, you can only use numeric and alphabetical characters and the special characters ~ ! @ # $ % ^ *( ) - _ = + [ { ] } ; : , . / \ ? " ; for this password.

  13. On the File to Export page, in the File name box, enter the location and name for the certificate. The location should be a share that other BizTalk Server computers can access. Use the .pfx extension for the certificate file. Then click Next.

  14. On the Completing the Certificate Export Wizard page, click Finish.

  15. In the Certificate Export Wizard dialog box, click OK.

After you export the encryption certificate on the BizTalk Server computer, export the public key.

Follow these steps on the client computer to export the public key from the client computer to the BizTalk Server computer receiving messages from the client computer (BTS-SRV).

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to export the public key to the first BizTalk Server computer (BTS-SRV)

To export the public key
  1. On the client computer, log on as the user who will run the application (you can use administrator or btsinstall). For BizTalk Server, log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

  2. In the Run dialog box, in the Open box, type mmc, and then click OK.

  3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

  4. In the Add/Remove Snap-in dialog box, click Add.

  5. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  6. On the Certificates snap-in page, select My user account, and then click Finish.

  7. In the Add Standalone Snap-in dialog box, click Close.

  8. In the Add/Remove Snap-in dialog box, click OK.

  9. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates - Current User, expand Personal, and then click Certificates.

  10. In the Results pane, right-click the certificate you want to export, point to All Tasks, and then click Export to start the Certificate Export Wizard.

  11. On the Welcome to the Certificate Export Wizard page, click Next.

  12. On the Export Private Key page, click No, do not export the private key, and then click Next.

  13. On the Export File Format page, leave the defaults, and then click Next.

  14. On the File to Export page, in the File name box, enter the location and name for the certificate, and then click Next.

  15. On the Completing the Certificate Export Wizard page, click Finish.

  16. In the Certificate Export Wizard dialog box, click OK.

Follow these steps on the BizTalk Server computer that receives messages from the client computer (BTS-SRV) to import the public key from the client computer.

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to import the public key to the appropriate certificate store.

To import the public key
  1. Log on to the BizTalk Server computer as a local administrator or as the btsinstall account.

  2. Click Start, click Run, type mmc, and then click OK.

  3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

  4. In the Add/Remove Snap-in dialog box, click Add.

  5. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  6. On the Certificates snap-in page, select Computer account, and then click Next.

  7. On the Select Computer page, make sure Local computer is selected, and then click Finish.

  8. In the Add Standalone Snap-in dialog box, click Close.

  9. In the Add/Remove Snap-in dialog box, click OK.

  10. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates (Local Computer), right-click Other People, point to All Tasks, and then click Import.

  11. On the Welcome to the Certificate Import Wizard page, click Next.

  12. On the File to Import page, click Browse.

  13. In the Open dialog box, open the location where you exported the public key in step 10 of the previous procedure, select the public key, and then click Open. This key should have a .cer file name extension.

  14. On the File to Import page, click Next.

  15. On the Certificate Store page, select Place all certificates in the following store, make sure that the certificate store is Other People, and then click Next.

  16. On the Completing the Certificate Import Wizard page, click Finish.

  17. In the Certificate Import Wizard dialog box informing you that the import was successful, click OK.

After you install the certificates on the BizTalk Server computers, you have to copy the thumbprint values for the certificates for use in following procedures.

You can also use the certificate deployment utility to retrieve the thumbprint values. For more information about using the certificate deployment utility to retrieve the thumbprint values, see Retrieving the Thumbprint Values.

To view the thumbprint
  1. Click Start, click Run, type mmc, and then click OK.

  2. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

  3. In the Add/Remove Snap-in dialog box, click Add.

  4. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  5. On the Certificates snap-in page, select Computer account, and then click Next.

  6. On the Select Computer page, make sure Local computer is selected, and then click Finish.

  7. In the Add Standalone Snap-in dialog box, click Close.

  8. In the Add/Remove Snap-in dialog box, click OK.

  9. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates (Local Computer), expand Other People, and then click Certificates.

  10. Right-click the certificate you want to view the thumbprint for, and then click Open.

  11. On the Details tab, scroll down until you see Thumbprint. Select the thumbprint value, and then press CTRL+C.

  12. Paste the thumbprint to a location where you can access it later on.

This section provides guidelines for configuring the database computer in the sample certificate management deployment. It includes guidelines for configuring SQL Server 2000, modifying the properties for Microsoft Distributed Transaction Coordinator (MS DTC), and copying data to the database for the sample application.

Follow these steps when installing and configuring the computer that is running SQL Server.

To configure SQL Server 2000
  1. The sample application assumes that this server is named SQL-SERVER. If you name this computer something different, you must modify the settings on the BizTalk Server.

  2. Add the computer that is running SQL Server to the CONTOSO domain.

  3. Install SQL Server 2000 on the computer. For more information about installing SQL Server 2000, see "Installing SQL Server" in SQL Server Books Online.

Follow these steps when modifying the properties for MS DTC.

To modify the properties for MS DTC
  1. Open Administrative Tools.

  2. Open Component Services.

  3. Right-click My Computer, and then click Properties.

  4. Click the MSDTC tab.

  5. Click Security Configuration.

  6. Click Security Settings, and make sure that the Network Client check box is selected.

  7. Close the dialog box and restart the computer.

Follow these steps to set up the sample database on the computer that is running SQL Server. This sample database contains business data about the purchase orders, and is independent from the BizTalk Server databases.

To set up the sample database on the SQL Server computer
  1. On the computer that is running SQL Server, log on as a SQL Server administrator.

  2. If you used the default settings for the location of the installation files, open Windows Explorer and open the \\<BizTalk Server Computer>\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder. Otherwise open the location you specified.

  3. Copy the Database folder to the computer that is running SQL Server.

  4. Locate the Database folder that you just copied from the BizTalk Server computer.

  5. Double-click mount_db.vbs. This file will mount the sample database that the sample application uses.

  6. Open SQL Server Enterprise Manager and verify that the ContosoOrder database has been successfully mounted.

Follow these steps to make sure the user account that will access the SQL Server database with the business data (sqladapter) has sufficient permissions to access the database.

To make sure the user account has correct rights
  1. Click Start, click All Programs, click Microsoft SQL Server, and then click Enterprise Manager.

  2. Expand Microsoft SQL Servers, expand SQL Server Group, expand (LOCAL) (Windows NT), expand Security, right-click Logins, and then click New Login.

  3. In the SQL Server Login Properties -New Login dialog box, on the Name box, type contoso\sqladapter.

  4. On the Database Access tab, select the Permit check box for the ContosoOrders database, and then click OK.

  5. Expand Databases, expand ContosoOrders, and then click Users.

  6. In the Results pane, right-click Contoso\sqladapter, and then click Properties.

  7. On the Database User Properties - contoso\sqladapter page, click Permissions.

  8. Make sure that EXEC is selected for the SaveOrder row, and that SELECT, UPDATE, and INSERT are selected for the IncomingOrders row.

  9. Click OK to exit the Database User Properties - ContosoOrders page.

  10. Click OK to exit the Database User Properties - BizTalk SQL Adapter Host Users page.

  11. Exit Enterprise Manager.

This section describes how to update the binding file with the new certificate keys. The binding file released with the sample was configured for a specific test environment. This step updates the binding file to match your particular environment.

Follow these steps to update the binding file.

To run the update file
  1. Log on to the BizTalk Server computer where you installed the directory and files for the sample deployment (BTS-SRV). If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder.

  2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders, and double-click the adjust_setup.bat file. This file helps update the binding file for your particular environment.

  3. If you did not use the recommended names for the computer that is running SQL Server and the client computer, enter the names of your SQL Server and application client computers.

  4. Retrieve the thumbprint values as described in Retrieving the Thumbprint Values or in Configuring Certificates for the Sample Deployment.

  5. In the Partner Thumbprint box, enter (or paste) the thumbprint for the client computer's encryption certificate (public key).

  6. In the BizTalk Thumbprint box, enter (or paste) the thumbprint for the BizTalk Server encryption certificate (public key).

This section describes how to run the batch file that runs the modified binding file to configure your BizTalk Server environment and to complete the configuration of the BizTalk Server objects.

Follow these steps to run the deployment file on the BizTalk Server computer.

To run the deployment file
  1. Log on to the BizTalk Server computer where you installed the directory and files for the sample deployment. If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders folder.

  2. Run the deploy.bat file. This file deploys the BizTalk Server orchestration and starts the sample orchestration. The batch file will finish with success messages.

Follow these steps to make sure the second BizTalk Server computer has the BizTalk assemblies in the global assembly cache.

To copy the BizTalk assembly to the second BizTalk Server computer
  1. Log on to the second BizTalk Server computer (BTS2-SRV) using the btsinstall account.

  2. Open Windows Explorer and locate \\BTS-SRV\c$\windows\assembly.

  3. Open a second instance of Windows Explorer and locate c:\windows\assembly.

  4. On \\BTS-SRV\c$\windows\assembly, click ContosoOrders, and drag the file to c:\windows\assembly.

Follow these steps to add the certificate information to the BizTalkDecrypter host.

To configure the BizTalkDecrypter Host
  1. Retrieve the thumbprint value for the BizTalk Server encryption certificate as described in Retrieving the Thumbprint Values or in Configuring Certificates for the Sample Deployment.

    ms865024.note(en-US,BTS.10).gifNote
    The public and private keys for a specific certificate (in this case the BizTalk Server encryption certificate) have the same thumbprint.

  2. Open BizTalk Server Administration.

  3. Expand Microsoft BizTalk Server 2004 (local), expand Hosts, right-click BizTalkDecrypter, and then click Properties.

  4. In the BizTalkDecrypter Properties dialog box, click the Certificate tab.

  5. In the Thumbprint box, type (or paste) the thumbprint for the BizTalk Server encryption certificate, and then click OK

To illustrate how BizTalk Server encrypts and decrypts messages in this sample deployment, the BizTalk orchestration drops a copy of the message it receives from the client computer into a folder. This message is encrypted. You can then move the message to another folder for the File receive adapter to pick it up, decrypt it, and put it in another folder. Follow these steps to create the folders where the messages will be dropped.

To create the folders for the File adapter
  1. Log on to the second BizTalk Server computer (BTS2-SRV).

  2. Create the following folders:

    C:\temp

    C:\temp\receive

    C:\temp\result

  3. Make sure the account running the instance of the BizTalkDecrypter host (btsrcv1) has read and write permissions to these folders.

This section describes how to run the application that starts the sample certificate management deployment. The sample application was written using Microsoft® Visual Studio® .NET 2003.

Follow these steps to run the certificate management installation program on the client computer.

To run the installation program on the client computer
  1. Log on to the client computer.

  2. If you used the default settings for the location of the installation files, open Windows Explorer and open the \\<BizTalk Server Computer>\Program Files\WSS Technical Guides\Certificate Management Technical Guide\App Installer\Debug folder. Otherwise open the location you specified. Select the location where you want to copy the sample files. Click Next.

  3. Copy App_Installer.msi to the client computer.

  4. Double-click App_Installer.msi.

  5. On the Welcome to the Certificate Management Sample App Setup Wizard page, click Next.

  6. On the License Agreement page, read the agreement. If you agree to abide by the license agreement, click the I Agree option, and then click Next.

  7. Select the location where you want the sample files to be copied. Click Next.

  8. On the Confirm Installation page, click Next.

  9. On the Installation Complete page, click Close to exit the installation program.

You are now ready to send a test message from the client computer to the BizTalk Server computers. Follow these steps to run the sample application.

To run the sample application
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click ContosoOrderProcessor.

  2. If your BizTalk Server computer is named BTS-SRV, go to step 5.

  3. If your BizTalk Server computer is not named BTS-SRV, click Setup.

  4. Change the entry for the BizTalk Host field to the correct name of your BizTalk Server computer. The Local Queue should be ContosoOrderOutput and the BizTalk Queue should be ContosoInputQueue.

  5. Change the values for Shirts, Pants, Socks, and Shoes. Click Order to send the order to the BizTalk Server. A confirmation XML message will be sent from the BizTalk Server and displayed in the Processed Orders text box.

    An order with the quantities that you specified is sent to the BizTalk Server for processing.

    An XML document confirming the order is returned to the sample application and displayed in the text box.

  6. Click the order, and then click Order Details. The Order Details window shows the encrypted message.

  7. Click Decrypt to see the decrypted message.

  8. Click Close to close the Order Details window.

To illustrate how BizTalk Server encrypts and decrypts messages in this sample deployment, the BizTalk orchestration drops a copy of the message it receives from the client computer into a folder. This message is encrypted. You can then move the message to another folder for the File receive adapter to pick it up, decrypt it, and put it in another folder. Follow these steps to see how BizTalk Server encrypts and decrypts a message.

To view an encrypted message in BizTalk Server
  1. Log on to the second BizTalk Server computer (BTS2-SRV).

  2. Open c:\temp\.

  3. Double-click one of the *.txt files, and verify that the file is MIME encrypted.

  4. Copy one of the encrypted files and drop it to c:\temp\receive for the File receive adapter to process it.

  5. The file will now appear on c:\temp\result. Open the file (*.xml) to verify that the file is now in clear text.

The following steps offer some possible ways to fix your deployment if you cannot run the sample application successfully,

To troubleshoot the sample deployment
  1. If you do not receive an XML document confirming the order, do the following:

    1. Make sure you restart the BizTalkServerApplication host instance in BTS-SRV after you add the BizTalk Message Queuing Adapter. For more information, see "Adding the BizTalk Message Queuing Adapter" in Configuring the BizTalk Server Computers.
    2. Make sure the sqladapter account has permissions to access the ContosoOrders database. For more information, see "Making Sure the User Account Has Correct Rights" in Configuring the SQL Server Computer.
  2. If you cannot decrypt the order, do the following:

    1. Make sure you are running the ContosoOrderProcessor application with the same user account that you used to request the certificate for the partner.
    2. On BTS-SRV, open c:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders and open contoso-bind.xml. Make sure the thumbprints for BizTalk Server and the partner are correct.
  3. If the thumbprints are incorrect, do the following:

    1. Open Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders
    2. Run cleanup.bat to undeploy the BizTalk ports, pipelines, and the orchestration.
    3. Run adjust-bind.bat. Make sure you type or paste the thumbprints in the correct boxes.
    4. Run deploy.bat to deploy the BizTalk ports, pipelines, and the orchestration.
  4. If you are still having problems with the sample deployment, use Health and Activity Tracking (HAT) and the Event Viewer to identify the issue. For more information about HAT, see Health and Activity Tracking in BizTalk Server 2004 Help.

This section describes how to remove the sample deployment components from your computers. To remove the sample deployment components, you must do the following:

  1. Remove the sample deployment application from APP-SRV.
  2. Run the cleanup application to remove the BizTalk Server objects.
  3. Remove the log files.
  4. Delete the ContosoOrders database.
  5. Remove the sample deployment application from BTS-SRV.

Follow these steps to remove the sample application from the client computer.

To remove the sample application
  1. Log on to the client computer and open the location where you copied App_Installer.msi.

  2. Double-click App_Installer.msi.

  3. On the Welcome to the Certificate Management Sample App Setup Wizard page, click Remove Certificate Management Sample App, and then click Finish.

  4. On the Installation Complete page, click Close to exit the installation program.

Follow these steps to run the cleanup application to undeploy the BizTalk ports, pipelines, and the orchestration.

To run the cleanup application
  1. Log on to the first BizTalk Server computer (BTS-SRV) using the btsinstall account.

  2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders.

  3. Run cleanup.bat to undeploy the BizTalk ports, pipelines, and the orchestration.

Follow these steps to remove the log files the sample application creates. By deleting these log files, you can remove all the directories associated with the sample deployment.

To remove the log files
  1. Log on to the first BizTalk Server computer (BTS-SRV) using the btsinstall account.

  2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders.

  3. Delete the following files:

    Binding1.log.htm

    Binding1.log.xml

    Binding2.log.htm

    Binding2.log.xml

    Binding3.log.htm

    Binding3.log.xml

    Undeploy.htm

    Undeploy.xml

    Undeploy2.htm

    Undeploy2.xml

Follow these steps to remove the ContosoOrders database from the computer that is running SQL Server.

To delete the ContosoOrders database
  1. On the computer that is running SQL Server, log on as a SQL Server administrator.

  2. Click Start, click All Programs, click Microsoft SQL Server, and then click Enterprise Manager.

  3. Expand Microsoft SQL Servers, expand SQL Server Group, expand (LOCAL) (Windows NT), expand Databases, right-click ContosoOrders, and then click Delete.

  4. On the confirmation message, click Yes.

  5. Exit Enterprise Manager.

Follow these steps to remove the sample application from your computers.

ms865024.note(en-US,BTS.10).gifNote
This also removes the certificate deployment utility. For more information about the certificate deployment utility, see Sample Certificate Deployment Utility.

To remove the sample application
  1. Click Start, click Control Panel, and then click Add or Remove Programs.

  2. In the Add or Remove Programs list, select Certificate Management Technical Guide, and then click Remove.

  3. On the confirmation message, click Yes.

This section provides the steps and results of a threat model analysis (TMA) that we did for the sample deployment. By walking you through the steps, this section gives you a better understanding of how a TMA works, and also describes the potential threats we identified for the sample deployment and how we mitigated them.

For additional information about threat modeling, see the Threat Model Analysis topic in BizTalk Server 2004 Technical Guide for Security and chapter 4 of Writing Secure Code, Second edition, by Michael Howard and David LeBlanc.

Before the main threat analysis meeting, we collected the following background information about our sample deployment:

  • Usage scenarios
  • Data flow diagrams (DFDs)
  • Boundaries and scope of the system
  • Boundaries between trusted and untrusted components
  • Configuration and administration model for the components
  • Assumptions about other components and systems

The sample depicts a Point of Sale (PoS) application in which a salesperson from Contoso requests inventory items for the store. The salesperson uses a custom application to submit the request for items. The application submits the request to BizTalk Server, where the appropriate orchestration processes the order. To illustrate how to use certificates in this architecture, the orchestration sends the order to a pipeline where it is encrypted in one BizTalk Server, and then the second BizTalk Server decrypts the order before additional processing occurs. BizTalk Server uses the order information to update the SQL Server database that contains business data. BizTalk Server does a warehouse inventory check, and then submits an encrypted acknowledgment and inventory status back to the salesperson. The salesperson then decrypts the message.

This PoS application is used in an intranet environment, and salespeople and managers have access to it. For our sample, the PoS application only has users; we have not defined administrators. Therefore, no user group needs special permissions for BizTalk Server. The users of the PoS application need permissions to put messages in Message Queuing (also known as MSMQ).

The user group accounts and individual group accounts are created in Active Directory on the domain controller.

The following figure shows the Level 0 data flow diagram (DFD) for the sample deployment.

Figure 11 Level 0 data flow diagram

Level 0 DFD

The data flow is as follows:

  1. The salesperson logs on to the client computer (APP-SRV) and uses a fixed form within the PoS application to choose the number of items to order (inventory request).
  2. When the form is submitted, the PoS application transforms the fixed form into an XML document, and sends it to BizTalk Server by using Windows Message Queuing (also known as MSMQ).
  3. The BizTalk Message Queuing receive adapter (running in the BizTalkServerApplication host in BTS-SRV) picks up the message. After the receive adapter does the initial processing of the message, it puts the message in the MessageBox database (SQL-SERVER). A BizTalk orchestration that has the right subscription picks up the message and processes it.
  4. To illustrate the encryption step, the orchestration sends the order document to a File send port (SaveEncryptedContosoOrder). The File send adapter picks up the message, encrypts it, and puts it in a file location.
  5. To illustrate the decryption step, the File receive adapter (running in the BizTalkEncrypter host in BTS2-SRV) picks up the message, decrypts it, and puts it in a file location in clear text.
  6. The orchestration passes the message to the SQL adapter (running in the BizTalkServerApplication host in BTS-SRV). The SQL adapter picks up the message and sends it to a stored procedure in the SQL Server database with the business data. The stored procedure enters the data into a database table and sends the message back to the SQL adapter. The SQL adapter puts the document back in the MessageBox database.
  7. The orchestration then passes the response message back to the PoS application by using the BizTalk Message Queuing send adapter (running in the BizTalkServerApplication host in BTS-SRV). The BizTalk Message Queuing adapter picks up the message from the MessageBox database, encrypts it, and puts it in the Message Queuing queue that the PoS application uses.
  8. The PoS application picks up the message. It appears as an encrypted message.
  9. The salesperson decrypts the message to view the details of the acknowledgment.

  • This sample PoS application is used in an intranet environment, and salespeople and managers have access to it.
  • At this point, only one user at a time can use the application.
  • The sample application retrieves business data from the business data database.
  • The sample application is not connected to the Internet.
  • Only users who have a valid account in the domain can use the sample application.

To create boundaries, we used different hosts as a security boundary between applications within BizTalk Server.

If you are using this sample to guide you in developing your own environment, we recommend that you use Internet Protocol security (IPSec) to restrict communication between servers and use a firewall to restrict access from the application server to the BizTalk Server computer and the databases.

Additionally, we recommend that you use different BizTalk Hosts to separate the processing functions from the receiving and sending functions, and that you create different hosts for each adapter.

Configuration

  • On the first BizTalk Server computer (BTS-SRV), we installed the BizTalk runtime, the master secret server, and the administration tools. On the second BizTalk Server computer (BTS2-SRV), we installed the BizTalk runtime and the Enterprise Single Sign-On service. There are no development tools on the BizTalk Server computers.
  • The server that contains the sample PoS application does not have any BizTalk Server components.
  • The computer that is running SQL Server contains both the business data database and the BizTalk Server databases.

Administration

Administrators can connect to the BizTalk Server to administer the BizTalk Server components and services.

This issue is not applicable; this is a stand-alone application.

This section describes the key steps and findings during the threat analysis meeting for the certificate management sample deployment.

At the beginning of the meeting, we reviewed the background information we collected before the meeting, and identified the entry points, trust boundaries, and flow of data.

Entry points

  • PoS application
  • Message Queuing

Trust boundaries

  • See "Boundaries and Scope of the System" in the previous topic.
  • See "Boundaries Between Trusted and Untrusted Components" in the previous topic.

Flow of data

  • See "Data Flow Diagrams" in the previous topic.

Using the STRIDE (Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges) method, we identified the following threats to the PoS application. Note that we listed all the threats we identified, even if we were already mitigating them.

Table 3 Threats to the PoS application

Threat Description Threat target Threat type

An unauthorized user can put messages in the queue.

If a user has write permissions to the queue from which BizTalk Server picks up messages, then that user can submit messages to BizTalk Server.

BizTalk Server environment

Spoofing identity

Tampering with data

Elevation of privileges

An unauthorized user can view the received message in the PoS application.

Any user who has access to the PoS application can view the acknowledgments that BizTalk Server sends to the application.

Message

Information disclosure

Access to private keys

If a user has access to the private keys, either when you receive them from the certification authority or when they are stored in the Personal certificate store, that user can use the private key to decrypt messages and/or sign messages.

Certificate keys

Spoofing identity

Tampering with data

Information disclosure

Access to public keys

Any users of the computer where you store the public keys has access to the public keys, because they are stored in the computer's Local Computer store. Users of this computer can use the public key to encrypt and/or verify signatures.

Certificate keys

Information disclosure

A malicious user can sniff data in the wire between BizTalk Server and the client computer.

By default, the communication between BizTalk Server and the client application is in the client computer that is running the PoS application text. A malicious user can sniff the data as it travels from one server to another.

Message

Information disclosure

Access to private keys after computer is reused

If you install private keys in a user's personal store, and then reuse the server for other purposes, the private keys may remain in the server, where a malicious user may obtain access to them.

Certificate keys

Spoofing identity

Tampering with data

Information disclosure

A malicious user can replace the receive location with a rogue receive location or server.

If a malicious user replaces the BizTalk receiving server with a rogue BizTalk Server, that server can intercept the messages.

Message

Spoofing identity

Tampering with data

Information disclosure

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.

By default, the communication between BizTalk Server and the SQL Server databases is in clear text. A malicious user can sniff the data as it travels from one server to another.

Message

Spoofing identity

Tampering with data

A malicious user can tamper with the application binaries.

If a malicious user has access to the network resources, that user may be able to locate the binaries for the PoS application, tamper with them, and cause unwanted behavior.

Test application

Tampering with data

Information disclosure

Denial of service

Elevation of privileges

We cannot prove that we received a message, or that we sent a reply.

If there are no good auditing mechanisms in place, then we may not be able to prove that a specific employee submitted an order, or that BizTalk sent an acknowledgment.

Message

Repudiation

Employees can order as may items as they want.

There should be a limit on how many items employees can order, requiring management approval to exceed that limit.

Inventory

Tampering with data

Elevation of privileges

ms865024.note(en-US,BTS.10).gifNote
While this is not a standard elevation of privileges threat (they cannot gain control of the system through this threat), employees currently can order more items than they should, which is a different form of elevation of privileges.

A malicious user can see and retrieve data in the Message Queuing queue.

If users can access the queue to which BizTalk drops messages, then they can read and modify the messages.

Message

Spoofing identity

Tampering with data

Information disclosure

A malicious user can insert a bad message into BizTalk Server.

A malicious user can identify the communication channel between the PoS application and BizTalk Server, and send unauthorized messages to BizTalk Server.

Message

Tampering with data

Spoofing identity

A malicious user can insert a bad message into the test application.

A malicious user can provide invalid data to the PoS application, which can help the user break into the stored procedure that BizTalk Server uses to retrieve business data.

Data in the business database

Tampering with data

Information disclosure

Elevation of privileges

A malicious user can use the stored procedure as an access point to the business database.

If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can take advantage of the stored procedure to access and modify the data in the business database.

Data in the business database

Tampering with data

Information disclosure

A malicious user can see data in the stored procedure.

If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can see and modify the data within the stored procedure.

Data in the business database

Tampering with data

Information disclosure

An unauthorized user can obtain data in the business database.

Only the people and processes that have to access the data in the business database should have access to the database.

Data in the business database

Tampering with data

Information disclosure

After the main threat modeling meeting, we reviewed the threats and used the DREAD rating (Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability) to identify the risk for each threat.

The following table lists the threats and their DREAD ratings.

Table 4 Threats and their DREAD ratings

Threat Threat type D R E A D Overall

An unauthorized user can put messages in the queue.

Spoofing identity

Tampering with data

Elevation of privileges

8

8

8

3

5

6.4

An unauthorized user can view the received message in the PoS application.

Information disclosure

7

8

7

4

8

6.8

Access to private keys

Spoofing identity

Tampering with data

Information disclosure

8

5

3

3

5

4.8

Access to public keys

Information disclosure

1

10

8

7

7

6.6

A malicious user can sniff data in the wire between BizTalk Server and the client computer.

Information disclosure

8

4

8

3

5

5.6

Access to private keys after computer is reused

Spoofing identity

Tampering with data

Information disclosure

8

5

3

3

4

4.6

A malicious user can replace the receive location with a rogue receive location or server.

Spoofing identity

Tampering with data

Information disclosure

8

10

3

7

4

6.4

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.

Spoofing identity

Tampering with data

8

10

8

3

5

6.8

A malicious user can tamper with the application binaries.

Tampering with data

Information disclosure

Denial of service

Elevation of privileges

10

5

5

8

4

6.4

We cannot prove that we received a message, or that we sent a reply.

Repudiation

6

10

5

5

4

6

Employees can order as may items as they want.

Tampering with data

Elevation of privileges

10

10

10

5

10

9

A malicious user can see and retrieve data in the Message Queuing queue.

Spoofing identity

Tampering with data

Information disclosure

8

9

7

4

5

6.6

A malicious user can insert a bad message into BizTalk Server.

Tampering with data

Spoofing identity

8

7

6

3

4

5.6

A malicious user can insert a bad message into the test application.

Tampering with data

Information disclosure

Elevation of privileges

8

9

6

3

4

6

A malicious user can use the stored procedure as an access point to the business database.

Tampering with data

Information disclosure

8

8

7

3

5

6.2

A malicious user can see data in the stored procedure.

Tampering with data

Information disclosure

8

8

8

3

5

6.4

An unauthorized user can obtain data in the business database.

Tampering with data

Information disclosure

10

7

7

10

7

8.2

After identifying the threats and their risks, we proceeded to identify the mitigation techniques for each threat.

The following table lists the threats, the mitigation techniques, and whether we implemented the mitigation for the PoS application. The threats are ordered from greater risk to lower risk.

Table 5 Threats in order of risk level

Threat Threat type Overall risk Mitigation techniques and technologies Implemented?

Employees can order as may items as they want.

Tampering with data

Elevation of privileges

9

Modify the application so that there is a limit to the number of items that a person can order.

An additional modification is to enable a manager to order more items, or to require manager approval for an employee to order more than the maximum allowed.

Yes. We implemented an upper limit of 100 items, and a lower limit of 0 items.

An unauthorized user can obtain data in the business database.

Tampering with data

Information disclosure

8.2

Create a separate host for the SQL adapter. Create a user group and account dedicated to this new host. Lock down access to the business database by granting permissions in SQL Server only to the members of the SQL User group. Give the SQL User group access to the business database as users only, and only give them permissions to the specific stored procedures they need access to.

Yes

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.

Spoofing identity

Tampering with data

6.8

Use Internet Protocol security (IPSec) to encrypt communication between BizTalk Server and SQL Server.

Yes

An unauthorized user can view the received message in the PoS application.

Information disclosure

6.8

Only people that have the private encryption certificate in the personal certificate store can view the message.

Only authorized users can access the PoS application.

Yes. Sample application first shows the message in encrypted form. Users must have a copy of the private certificate in their personal store to decrypt the message

A malicious user can see and retrieve data in the Message Queuing queue.

Spoofing identity

Tampering with data

Information disclosure

6.6

Use encryption to make sure that only authorized users and processes can read the message.

Use Message Queuing client authentication to restrict access to the queue.

ms865024.note(en-US,BTS.10).gifImportant
Message Queuing client authentication only works when the client and the server are on the same domain controller.

No

Access to public keys

Information disclosure

6.6

By default, public keys are designed to be shared with multiple parties. A person with the public key can only encrypt messages and verify digital signatures. The disclosure of public keys does not pose a significant risk to your company.

However, a malicious user can use the public key to encrypt messages it sends to you. If you do not have a mechanism in place for authenticating the sender, such as digital signatures, a malicious user can create a denial of service attack by sending invalid encrypted messages.

No.

A malicious user can replace the receive location with a rogue receive location or server.

Spoofing identity

Tampering with data

Information disclosure

6.4

Follow the recommendations in Assembly Deployment Security Recommendations in BizTalk Server 2004 Help to protect the assembly that contains the receive location and to restrict access to the assembly files.

You must place your computers in a safe environment, and limit access to the computers that contain business-critical information, such as the databases.

Yes.

A malicious user can tamper with the application binaries.

Tampering with data

Information disclosure

Denial of service

Elevation of privileges

6.4

While not part of the sample solution, the data center administrators have to limit access to the application binaries.

Administrators must remove the binary file after deploying the BizTalk assemblies.

You can also use signed assemblies to secure assemblies from end to end.

No

An unauthorized user can put messages in the queue.

Spoofing identity

Tampering with data

Elevation of privileges

6.4

Access to the Message Queuing queue should be restricted to only the accounts that have to drop (write) and pick up (read and delete) messages from the queue.

Only the service account for the BizTalk Message Queuing host should be able to write to the Message Queuing queue.

No

A malicious user can see data in the stored procedure.

Tampering with data

Information disclosure

6.4

Use different user groups for each BizTalk Host. Have a host dedicated to the SQL adapter. In SQL Server grant permissions only to the members of the SQL User group, and give this group user access to the business database, and permissions to the specific stored procedures they have to run.

Yes

A malicious user can use the stored procedure as an access point to the business database.

Tampering with data

Information disclosure

6.2

As with the previous threat, the SQL User group should only have permissions to the specific stored procedures they have to run.

Yes

We cannot prove that we received a message, or that we sent a reply.

Repudiation

6

Use the BizTalk tracking features, and the standard log files.

ms865024.note(en-US,BTS.10).gifImportant
While this mitigation can help you prove that you sent or received a message, it may not meet the requirements for legal auditing.

Yes

A malicious user can insert a bad message into the test application.

Tampering with data

Information disclosure

Elevation of privileges

6

Only authorized users can access the PoS application.

Processes downstream should verify that the message came from an authorized user.

No

A malicious user can insert a bad message into BizTalk Server.

Tampering with data

Spoofing identity

5.6

Do not use default host and group names.

Use different user groups for each BizTalk Host. Have a different host for send and receive for each adapter, processing, and tracking.

Use the BizTalk S/MIME security features to prove the identity of the sender (from either direction) and to validate that the incoming request is valid. Drop the message if the incoming request is not valid.

Somewhat. We have separate hosts and groups, but do not use S/MIME.

A malicious user can sniff data in the wire between BizTalk Server and the client computer.

Information disclosure

5.6

Use encryption certificates to make sure that only authorized users can access the message.

Yes

Access to private keys

Spoofing identity

Tampering with data

Information disclosure

4.8

Modify PoS application so that it runs under a service account. This way you have to store the private key in one location. Restrict access to the PoS application by using DACLs

No

Access to private keys after computer is reused

Spoofing identity

Tampering with data

Information disclosure

4.6

Use strong passwords for all accounts, including those that have certificates in the personal certificate store.

Revoke certificates that you are no longer using.

Remove the certificates from the personal certificate stores before reusing the computer.

No

The sample certificate deployment utility helps you automate the installation of certificates in the appropriate certificate stores of selected computers that are running Microsoft® BizTalk® Server 2004.

The utility installs public certificates in the Other People certificate store of the selected BizTalk Servers. For private certificates, it does the following:

  • Prompts you for the password for the user account under which each host instance on the selected BizTalk Server computers is running.
  • Logs on to each BizTalk Server as each account.
  • Installs the private key certificate in the Personal certificate store for each account.

As described in previous sections, to send and receive encrypted or signed messages, you must install the certificates in the appropriate certificate store on each BizTalk Server runtime computer. If you have a small number of partners, or a small BizTalk Server deployment, an administrator can easily take on the task. If you have many partners, logging on to each BizTalk Server computer and manually installing their certificates can become a complex task.

This section provides information about how to use the sample certificate deployment utility.

This section describes the steps that you must follow to configure the BizTalk Server environment to use the certificate deployment utility. These steps are:

  1. Run the private certificate handler installation program.
  2. Create an account for creating and accessing the log files.
  3. If you have not done so already, mount the Certificate_logging database on the computer that is running SQL Server, and make sure the logging account has sufficient permissions to access the database.
  4. Configure the certificate logging Web service to use the logging account.
  5. Update the certificate logging Web service configuration file with the correct name for the computer hosting the Web service.
ms865024.note(en-US,BTS.10).gifImportant
You must have already run the certificate deployment utility installation program. The certificate deployment utility is installed as part of the sample certificate management deployment. If you have not done so, follow the instructions for "Running the Installation Program for the Sample Deployment" in Configuring the BizTalk Server Computers to install the certificate deployment utility on a BizTalk Server computer.

Running the Private Certificate Handler Installation Program

Follow these steps on both BizTalk Server computers (send and receive) to run the private certificate handler installation program. To install private certificates on remote computers, you must configure the target computers to make sure they have the files needed to install the certificates remotely. In other words, you must install the private certificate handler file on all the BizTalk Server computers where you want to install certificates by using the certificate deployment utility.

To run the private certificate handler installation program
  1. Log on to the BizTalk Server computer where you installed the directory and files for the sample deployment. If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\phc_installer\debug folder.

  2. Copy Pch-install.msi onto the BizTalk Server computers where you want to use the certificate deployment utility to install certificates.

  3. Log on to the BizTalk Server computer where you copied the Pch-install.msi file.

  4. Run Pch-install.msi. This installation program installs the utility files on the BizTalk Server computer so that the certificate deployment utility can reference the functions in this file for managing private certificates.

  5. On the Welcome to the Certificate Management Private Certificate Handler Set up Wizard page, click Next.

  6. On the License Agreement page, read the agreement. If you agree to abide by the license agreement, click the I Agree option, and then click Next.

  7. Select the location where you want the sample files to be copied. Click Next.

  8. On the Confirm Installation page, click Next.

  9. On the Installation Complete page, click Close to exit the installation program.

  10. Repeat this procedure on the other BizTalk Server computer.

Creating an Account for Certificate Logging

Follow these steps to create an account to create and access the certificate deployment utility log.

To create an account for certificate logging
  1. Log on as a domain administrator to the domain controller.

  2. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  3. In the Active Directory Users and Computers window, expand <domainname>.com, right-click Users, point to New, and then click User.

  4. In the New Object - User dialog box, type a first name for the account, type the account name you want to use for accessing the logging database Certificate_logging (for example, certlogging) for the User logon name, and then click Next.

  5. In the Password box, type a password for the account, and then in the Confirm password box, type the password again.

  6. Select User cannot change password, and then click Next.

  7. Click Finish.

Mounting the Certificate_logging Database

Follow these steps to mount the Certificate_logging database on the computer that is running SQL Server. This database contains the logs for the certificate deployment utility.

To mount the Certificate_logging database
  1. On the computer that is running SQL Server, log on as a SQL Server administrator.

  2. If you used the default settings for the location of the installation files, open Windows Explorer and open the \\<Installation Computer>\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder, where <Installation Computer> is the computer where you installed the certificate management files. Otherwise open the location you specified.

  3. Copy the Database folder to the computer that is running SQL Server.

  4. Locate the Database folder that you just copied from the BizTalk Server computer.

  5. Double-click mount_db.vbs. This file will mount the sample database that the sample application uses.

  6. Click Start, click All Programs, click Microsoft SQL Server, and then click Enterprise Manager.

  7. Expand Microsoft SQL Servers, expand SQL Server Group, expand (LOCAL) (Windows NT), expand Security, right-click Logins, and then click New Login.

  8. In the SQL Server Login Properties -New Login dialog box, in the Name box, type the account you created earlier for certificate logging.

  9. On the Database Access tab, select the Permit check box for the Certificate_logging database.

  10. On the Database roles for 'Certificate_logging' section, select db_owner, and then click OK.

  11. Exit Enterprise Manager.

Configuring the Certificate Logging Web Service

Follow these steps to configure the certificate logging Web service to use the account you created.

To configure certificate logging
  1. Log on to the computer where you installed the certificate management files with an account with administrative rights.

  2. Click Start, click Control Panel, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  3. Expand <computer name>, expand Web sites, expand Default Web Site, right-click PrivateCertLog, and then click Properties.

  4. In the PrivateCertLog Properties window, on the Directory Security tab, in the Authentication and access control area, click Edit.

  5. In the Authentication Methods dialog box, select Enable anonymous access, type the user name and password of the certificate logging account you created earlier, and then click OK.

  6. Click OK to close the PrivateCertLog Properties window.

  7. Close Internet Information Services (IIS) Manager.

Updating the Certificate Logging Web Service Configuration File

Follow these steps to update the configuration file for the certificate logging Web service to reference the BizTalk Server computer where you installed the certificate deployment utility.

To update the certificate logging Web service configuration file
  1. Log on to the computer where you installed the certificate management files with an account with administrative rights.

  2. Open Windows Explorer and open <Install directory>:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\CertDeployUtility\bin\debug, right-click CertDeployUtility.exe.config, and then click Edit.

  3. Replace bts-srv with the name of the computer where you installed the certificate management files, and save the file.

The first step for using the certificate deployment utility is to generate a list of the BizTalk Server computers that are running host instances. After you generate this list, you can edit it, save it for future use, and retrieve it later. After you have the list, you can install or remove certificates. This section describes how to list the BizTalk Host instances available in your deployment. This section includes guidelines for:

  • Generating a list of host instances
  • Editing a list of host instances
  • Saving a list of host instances
  • Loading a list of host instances

Generating a List of Host Instances

Follow these steps to generate a list of host instances in your BizTalk Server environment.

To generate a list of host instances
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. Click Generate List.

  3. The utility enumerates the host instances in your BizTalk Server environment, and displays them in the BizTalk Host Instance List section.

Editing a List of Host Instances

Follow these steps to edit the list of host instances. For example, you might delete a specific host instance in the list if you do not want the utility to deploy a certificate to that particular host instance.

To edit a list of host instances
  1. Generate a list of host instances as described in the previous procedure.

  2. In the BizTalk Host Instance List section, click the first column in the row for the host instance that you want to remove from the list, and then press the DELETE key.

Saving a List of Host Instances

Follow these steps to save a list of host instances. You can create and save a list that contains the BizTalk Host instances running specific processes. For example, you might save a list of the host instances that receive, process, and send messages from a particular partner, and use the list later when you update the certificates for that partner.

To save a list of host instances
  1. Generate a list of host instances as described earlier in this topic in "Generating the List of Host Instances."

  2. After the utility enumerates and displays the list of host instances, click Save List.

  3. Specify a location for saving the list, and then click Save.

Loading a List of Host Instances

Follow these steps to load a list of host instances that you previously saved.

To load a list of host instances
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. Click Load List.

  3. Specify the location of the saved list that you want to load, and then click Open.

This section provides instructions on how to use the certificate management utility to install public key certificates to the Other People certificate store of the BizTalk Server computers.

Deploying Public Certificates on the BizTalk Server Computers

Follow these steps to deploy the public certificates on the BizTalk Server computers by using the certificate deployment utility.

To deploy public certificates on the BizTalk Server computers
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. Generate a new host instance list, or load a previously saved one. For more information about generating and loading host instance lists, see Listing BizTalk Server Host Instances.

    <No Change>
  3. Click Deploy Public Certificates. The Select Public Certificates to Deploy screen appears.

  4. Click Add.

  5. On the Open dialog box, locate the public certificates directory, select the public key certificate you want to install, and then click Open.

  6. If you want to install more than one public certificate on the BizTalk Server computers in the BizTalk Host Instance List, repeat steps 4 and 5.

  7. Click Deploy. The application will now send the certificates to the BizTalk Server computers listed on the BizTalk Host Instance List. If the deployment of the public certificates is successful, you will return to the Certificate Deployment Utility dialog box. If an error occurs, an error message will appear.

This section provides instructions on how to use the certificate management utility to install a private certificate in the Personal certificate store for the user accounts of a selected list of host instances.

ms865024.note(en-US,BTS.10).gifNote
The private key certificate must be in shared directory that all BizTalk Server computers have access to. Only a Windows® administrator account that you use for installing the certificates remotely needs access to this share.

Deploying Private Certificates on the BizTalk Server Computers

Follow these steps to deploy private certificates on the BizTalk Server computers by using the certificate deployment utility.

To deploy private certificates on the BizTalk Server computers
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. Generate a new host instance list, or load a previously saved one. For more information about generating and loading host instance lists, see Listing BizTalk Server Host Instances.

  3. Click Deploy a Private Certificate. The Private Key Certificate Key Deployment screen appears.

  4. Click Browse. The Open dialog box appears.

  5. In the File name box, type the share path where the private certificate is stored.

  6. Select the private key that BizTalk Server will use to decrypt messages it receives from the sample application, and then click Open.

  7. In the File Password box, type the password for accessing the private certificate.

    ms865024.note(en-US,BTS.10).gifImportant
    If you use the certificate deployment utility to deploy private key certificates to BizTalk Server computers, you can only use numerical and alphabetical characters and the special characters ~ ! @ # $ % ^ *( ) - _ = + [ { ] } ; : , . / \ ? " ; for this password.

  8. In the Remoting Credentials section, enter the user name and password of the account you will use to install the certificates on the remote computers. This account must be a Windows administrator on all the computers you will connect to.

  9. Click Deploy.

  10. For each BizTalk Server computer in the BizTalk Host Instance List, a Deploying Private Key Certificate dialog box appears.

  11. The Target Account for Certificate section contains information about the account for the host instance. The private key certificate will be deployed in the Personal certificate store for this account. In the Password box, enter the password for the user account.

  12. Click Deploy to install the certificate in the Personal certificate store. If there are other host instances, another Deploying Private Key Certificate dialog box will appear.

    -or-

    Click Skip One if you do not want to install the private key certificate in the Personal certificate store of the indicated host instance account.

    -or-

    Click Cancel All if you do not want to continue the deployment operation.

  13. Click Private Cert Log on the main Certificate Deployment Utility screen to view the private certificate deployment results.

This section describes how to retrieve the thumbprints for the public and private keys for each company (in this example, the application client computer and the BizTalk Server deployment).

Using the Certificate Deployment Utility to Retrieve Thumbprints

Follow these steps when you are running the certificate deployment utility to retrieve thumbprints.

To read a public key certificate thumbprint
  1. Run CertDeployUtility.exe.

  2. Click Read Thumbprint.

  3. Specify the location that contains the public key for the application client computer. This public key file has a .cer extension.

  4. Click Open Certificate. The utility displays the certificate details.

  5. Select the second row in the box (the thumbprint value), and then click Copy Selected Info.

  6. In the confirmation dialog box notifying you that the thumbprint was successfully copied to the clipboard, click OK.

    The thumbprint value is now copied so that you can paste it into the appropriate text box as described in .

  7. Update the thumbprint value for the application client computer by pasting the thumbprint value.

  8. After updating the thumbprint value for the application client computer in the binding file, repeat steps 1 through 6 to retrieve the thumbprint value for the BizTalk Server computers.

  9. Go to the next topic to paste (update) the thumbprint value for the public key. Then return to this topic to retrieve the thumbprint value for the private key.

  10. Copy the thumbprint value to a temporary location like Notepad.

  11. Now that you have obtained the public key certificate thumbprints, you have to obtain the private key certificate thumbprints for the BizTalk Server receive computer.

To read a private key certificate thumbprint
  1. Click Read Thumbprint.

  2. Specify the location that contains the private key for the BizTalk Server computer. This private key file has a .pfx (BizTalk private key) file name extension.

  3. Enter the password in the Password for Private Key Certificate field.

    ms865024.note(en-US,BTS.10).gifImportant
    If you use the certificate deployment utility to deploy private key certificates to BizTalk Server computers, you can only use numerical and alphabetical characters and the special characters ~ ! @ # $ % ^ *( ) - _ = + [ { ] } ; : , . / \ ? " ; for this password.

  4. Click Open Certificate. The utility displays the certificate details.

  5. Select the second row in the box (the thumbprint value), and then click Copy Selected Info.

  6. Copy the thumbprint value to a temporary location like Notepad.

  7. Now that you have obtained the thumbprints, you are ready to run the setup file on the BizTalk Server receive computer.

At this point, you have deployed the sample application to the database, so both of the BizTalk Host instances running on the two BizTalk Server computers are ready to process this data.

This section provides information about how to use the certificate management utility to delete public and private certificate keys from the certificate stores on the BizTalk Server computers.

Deleting Public Certificates

Follow these steps to delete public certificates.

To delete public certificates
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. In the Certificate Deployment Utility dialog box, generate a new list or load an existing list. For information about generating a new list or loading an existing list, see Listing BizTalk Server Host Instances.

  3. Click Delete a Certificate.

  4. In the Certificate Thumbprint dialog box, enter the thumbprint for the public certificate that you want to remove.

  5. Select Public certificate, and then click Delete. The Certificate Deployment Utility removes the specified certificate from the Other People certificate store of each computer on the BizTalk Host Instance list. For information about obtaining the thumbprint, see Retrieving the Thumbprint Values.

Deleting Private Certificates

Follow these steps to delete private certificates.

To delete private certificates
  1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click Certificate Management Utility. The Certificate Management Utility appears.

  2. In the Certificate Deployment Utility dialog box, generate a new list or load an existing list. For information about generating a new list or loading an existing list, see Listing BizTalk Server Host Instances.

  3. Click Delete a Certificate.

  4. In the Certificate Thumbprint dialog box, enter the thumbprint for the private certificate that you want to remove. For information about obtaining the thumbprint, see Retrieving the Thumbprint Values.

  5. Select Private Certificate.

  6. In the Remoting Credentials section, enter the user name and password of the account you will use to delete the certificates on the remote computers. This account must by a Windows administrator on all the computers you will connect to.

  7. Click Delete. The Deleting Private Key Certificate dialog box appears.

  8. The Target Account for Certificate section contains information about the account for the host instance. The private key certificate will be deleted from the Personal certificate store for this account. In the Password box, enter the password for the user account.

  9. Click Delete to remove the certificate from the Personal certificate store. If there are other host instances, another Deleting Private Key Certificate dialog box will appear.

Applying the Microsoft Operations Framework (MOF) process model to the management of Microsoft® BizTalk® Server 2004 certificates can help you make sure that you have appropriate processes in place at the different stages of the release life cycle. By looking ahead at all the life cycle stages where certificate management appears, you can make the installation, maintenance, and troubleshooting of certificates in your environment easier.

This section contains information about the MOF processes where you may want to consider certificate management tasks.

The Microsoft Operations Framework (MOF) provides guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of Microsoft products and technologies. MOF provides operational guidance in the form of white papers, operations guides, assessment tools, best practices, case studies, templates, support tools, and services. This guidance addresses the people, process, technology, and management issues pertaining to complex, distributed, and heterogeneous IT environments.

The MOF process model enables companies to:

  • Facilitate consistent IT service management across service solutions
  • Establish a structure for IT functions, processes, and procedures
  • Represent a life cycle approach

Central to the MOF process model is its division into four quadrants of operational processes and procedures, named service management functions (SMFs). The SMFs are the foundation-level best practices and prescriptive guidance for operating and maintaining an IT environment.

The following figure shows the MOF processes where you may want to consider certificate management.

Figure 12 MOF processes where you may want to consider certificate management

<No Change>

The changing quadrant includes the service management functions (SMFs) required to identify, review, approve, and incorporate change into a managed IT environment. This includes changes in software, hardware, documentation, roles and responsibilities, and so on, as well as specific process and procedural changes.

Change Management

Change management is responsible for changes in technology, systems, applications, hardware, tools, documentation, and processes, as well as changes in roles and responsibilities.

During the change management process, as part of designing your BizTalk Server implementation, you can do the following:

  • Determine what company you are going to use as your certification authority, and the process for obtaining certificates from them.
  • Identify which public certificates you need from your partners. For more information about how BizTalk Server uses certificates, see BizTalk Server 2004 and Certificates.
  • Determine how you are going to receive public certificates from your partners.
  • Identify which public certificates you have to make available to your partners.
  • Determine how you are going to make public certificates available to your partners.
  • Determine where you are going to store certificates. For more information, see Certificate Management Best Practices.
  • Determine how you are going to manage those certificates.

Configuration Management

Configuration management is responsible for identifying, controlling, and tracking all versions of software, hardware, documentation, processes, procedures, and all other components of the IT environment under the control of change management.

During the configuration management process, you have to create a detailed plan for how you are going to install the certificates in each store, the process for verifying the trust chain of the certificates, and the process for renewing certificates and for requesting renewed certificates from your partners. For more information about how BizTalk Server uses certificates, see BizTalk Server 2004 and certificates.

Release Management

The focus of release management is to facilitate the introduction of software and hardware releases into the managed IT environment. Release management is the coordination point between the release development and project teams and the operations groups responsible for running the release in production.

During the release management process, you can do the following:

  • Determine the process for obtaining certificates from the certification authority.
  • Determine how you are going to receive public certificates from your partners.
  • Determine how you are going to make your public certificates available to your partners.
  • Determine the process for storing the certificates in the appropriate certificate store on the servers that need them. For more information about how BizTalk Server uses certificates, see BizTalk Server 2004 and certificates.

The operating quadrant includes the SMFs required to monitor, control, manage, and administer service solutions daily to achieve and maintain service levels within predetermined parameters.

Security Administration

Security administration is responsible for maintaining a safe computing environment. Security is an important part of the infrastructure of the enterprise.

During the security administration process, you can do the following:

  • Establish the process for retrieving the latest certificate revocation list.
  • After you receive your public-private key pairs from the certification authority, store them in a secure location.
  • Follow account and passwords best practices.

The supporting quadrant includes the SMFs required to identify, assign, diagnose, track, and resolve incidents, problems, and requests within the approved requirements that are contained in the service level agreements.

The optimizing quadrant includes the SMFs that contribute to maintaining business and IT alignment by focusing on decreasing IT costs while maintaining or improving service levels. This includes review of outages and incidents, examination of cost structures, staff assessments, availability and performance analysis, and capacity forecasting.

Service Level Management

The goal of service level management is to maintain and continuously improve IT service quality, through a constant cycle of negotiating and monitoring service level requirements. The successful service level management function causes an improvement in service quality, greater levels of customer productivity, and ideally, a reduction in the overall cost of services provided.

During the service level management process, you can do the following:

  • Assess how to obtain certificates from partners; you may be able to optimize or streamline the process.
  • Decide whether to use party resolution to identify partners in the system, and whether to use signing certificates to resolve the parties.
  • Decide whether to use the sample application to automate the installation of certificates. For more information about the sample application, see Sample Certificate Deployment Utility.

Availability Management

The single goal of availability management is to make sure that the customer can use a particular IT service at any time.

For the availability management process, you can establish a mechanism for notifying the IT personnel when a certificate is about to expire, or whether a certificate you use is in the latest certificate revocation list. For example, you can create a rule in Microsoft Operations Manager (MOM) that notifies the IT personnel two weeks before a certificate expires, so that they have enough time to request a new certificate from the partner, and therefore minimize the downtime because of expired certificates. You can also establish mechanisms to automatically send your latest public certificates before the current ones expire.

Security Management

Security management provides higher-level guidance that tells which security policies and guidelines should exist.

For certificate management, do a threat model analysis of how you intend to communicate with your partners to identify the assets and threats. Identify which of those threats you can reduce by using certificates, and determine whether that is the best way to reduce the threats.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft