Share via


Managing message authentication

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Managing message authentication

Message authentication, which confirms that a message has not been tampered with and can be used to verify the identity of the sender of a message to the receiver, is implemented using certificates. Messages are authenticated asynchronously without the sender and the receiver communicating with one another.

The use of message authentication is optional. Message Queuing applications are not required to use authentication when sending or receiving messages. It should be noted that the use of message authentication slows the transfer of messages. When used, Message Queuing applications that send or receive authenticated messages must use the cryptographic service provider installed by default with Windows Server 2003 family operating systems, and which is needed for both message authentication and encryption. For more information on message encryption, see Encryption for Message Queuing.

For more information on authentication for Windows Server 2003 family, see Authentication, in Windows help.

For more information on certificates for Windows Server 2003 family, see Certificates overview in Windows help.

In addition to confirming that no tampering has been done to a message, message authentication can be used to verify the identity of the user who sent the message. Authentication is done at the request of the sending application, which indicates that a message is to be authenticated by setting its authentication level.

An authenticated message is sent with a digital signature and a certificate. Digital signatures are created and validated using public-key (asymmetric) encryption. In Message Queuing, the sender uses the private key to create a digital signature, and the receiver uses the public key in the certificate attached to the message to validate the digital signature.

Because Message Queuing is an asynchronous messaging system, the source computer and the destination computer are not assumed to be online and connected at the same time.

The sender of a message cannot always be authenticated. For example, before you can authenticate the sender of a message sent between computers in the same forest with access to Active Directory, a user certificate must be registered in Active Directory. Registering a certificate in Active Directory associates the certificate with the owner's security ID (SID). You can also use the internal user certificate created on the local computer during setup, which is automatically registered the first time you log on to the computer.

Then, when an authenticated message is sent, a Message Queuing application on the source computer creates a digital signature for the message, attaches the digital signature, the SID, and the applicable certificate to the message, and sends the message. The Message Queuing service on the destination computer validates the digital signature and then queries the applicable directory service to see whether the SID/certificate pair is registered. If the SID/certificate pair is registered, the message is considered authenticated and is placed in the destination queue.

When the sending application indicates that a message is to be authenticated by setting its authentication level, the Message Queuing runtime code does the following:

  1. Retrieves the applicable certificate. By default the internal certificate is retrieved. However an external certificate is used if one is provided on the sender certificate property. For more information, see Managing user certificates.

  2. Obtains the private signing key for the certificate used. For Windows Server 2003 family computers, certificates are stored in certificate stores. Certificates can also be found in a public certificate store, but Message Queuing will not accept these. In the case of external certificates, Message Queuing searches for the private key in the personal certificate store (the external certificate must be registered there). For internal certificates, Message Queuing locates the private key internally.

  3. Computes a hash value from a fixed limited portion of the message using a hash algorithm. The default hash algorithm is the Secure Hash Algorithm (SHA).

  4. Encrypts the hash value using private key obtained in step 2 to create a digital signature.

  5. Attaches the digital signature, the security ID (SID), the name of the hash algorithm, and a digital certificate containing the public cryptographic key for the source computer to the message.

On the destination computer, the Message Queuing service does the following:

  1. Computes a hash value from a fixed limited portion of the message using the same hash algorithm as the source computer.

  2. Decrypts the digital signature attached to the message using the public cryptographic key from the digital certificate to obtain a second hash value.

  3. Compares the two hash values to confirm that the message was not tampered with during delivery.

  4. If the values match, locates the user certificate in Active Directory and verifies that the user who registered the certificate matches the sender (the SID) listed on the message. If the hash values do not match, the message is discarded, and a negative acknowledgment is returned to the sending application, if such an acknowledgment was requested.

In this case, the digital signature uniquely identifies the user who sent the message as well as the message itself. Because no user can digitally sign a message with another user's identity, no user can deny having sent a message if it contains a validated digital signature that can be identified with a specific sender.

You can also send authenticated messages to connector applications. The intermediary Message Queuing server (running the connector application) can validate authenticated messages.

You can specify whether or not a queue accepts only authenticated messages. For more information, see Allow only authenticated messages on queues.

Authentication in workgroup mode

When authenticating messages when the receiving computer is in workgroup mode, you cannot work with user certificates registered in Active Directory to map the certificate to the respective user security ID (SID). Instead, do the following:

On the sender computer:

  • The user gets an external certificate from a CA that is trusted by both the sender and the receiver, particularly the receiver.

  • Set Message Queuing to use this certificate when sending the message (use MQGetSecurityContextEx).

  • Message Queuing finds the private key and attaches the signature, but does not add the SID (use MQMSG_SENDERID_TYPE_NONE).

On the receiver computer, the procedure is the same as that described above for an Active Directory computer, except that:

  • The Message Queuing service does not attempt to locate the certificate in Active Directory.

  • The user must verify the certificate by verifying the certificate chain (use CertGetCertificateChain and CertVerifyCertificateChainPolicy).

For more information on internal certificates, see Managing user certificates.

For more information on cryptographic keys used by Message Queuing, see "Cryptographic keys" in Encryption for Message Queuing.