Freigeben über

HTTPS authentication

  • Artikel

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

HTTPS authentication

Using HTTPS to send messages ensures authentication of users requesting access to Message Queuing resources by means of a Web server, by establishing a Secure Sockets Layer (SSL) connection for secure communication between a sender and recipient. The sender is always regarded as the SSL client, and the recipient is regarded as the SSL server, regardless of whether the computers are running Message Queuing server or client software. Note that authentication for the purpose of establishing an SSL session is not the same as message authentication, which confirms that a message has not been tampered with and can be used to verify the identity of the message sender. For information about message authentication, see Managing message authentication.

Two kinds of certificates are used in HTTPS authentication:

  • Server certificates. This certificate contains information about the server that allows a client to identify the server before sharing sensitive information.

  • Client certificates. This certificate contains personal information about the user and identifies the SSL client (the sender) to the server.

Server certificates

Before an SSL connection can be established for sending messages, the recipient computer requires a server certificate that resides in the Personal store under Certificates (Local Computer) in the Certificates snap-in on the recipient computer.

For instructions on obtaining a server certificate from a CA and installing it, see Obtain server certificates for HTTPS messaging.

A server certificate obtained from a CA can be issued to the NetBIOS name or full DNS name of a computer. However, when HTTPS messages are sent, the destination specified in messages must be identical to the computer name in the recipient's server certificate. Thus, when only the NetBIOS name of the destination (for example, with a direct format name of the form DIRECT=HTTPS://msmqserv/msmq/private$/q1) is used to send messages within the same forest over an intranet to a computer whose server certificate contains the full DNS name, authentication fails. Consequently, when Message Queuing tries to create an SSL session, it receives a warning that the name in the certificate does not match the name of the destination, and the messages sent in this way accumulate in the outgoing queue.

Verifying server certificates on the sender computer

IIS on the recipient side must send the recipient's server certificate to the sender for authentication. This server certificate, which contains the signature of the certification authority (CA), the recipient's public key, additional information about the recipient, and an expiration date, must be from a CA that the sender trusts. To authenticate the recipient computer, the sender verifies that it trusts the CA and validates the signature in the recipient's server certificate.

When a sender computer trusts a CA, such as VeriSign or Microsoft Certificate Services, it has a certificate from that CA containing the CA's signature and public key in the Trusted Root Certification Authorities store under Certificates (Local Computer) in the Certificates snap-in. For instructions on importing a CA certificate on the sender computer from Microsoft Certificate Services, see Import a CA certificate from Microsoft Certificate Services.

Client certificates

An additional optional security component can be required for SSL sessions if IIS on the recipient side also requests the sender's client certificate for authentication. Client certificates are also obtained from a trusted CA and are stored in the MSMQ\Personal store under Certificates - Service (Message Queuing) on Local Computer in the Certificates snap-in on the sending computer. For information about obtaining and installing a client certificate, see Obtain client certificates.

Mapping client certificates

After a Web resource is configured to require an SSL channel, it still needs to be protected from unauthorized access. Since the anonymous user account has default write permissions for the physical MSMQ directory in IIS, and default IIS behavior is to ignore client certificate authentication, any user can send HTTPS messages. After client certificates are enabled, you can further protect content by creating mappings that relate the information contained in a client certificate to a Windows user account. For instructions, see Enable client certificates. Mapping is flexible, with one-to-one mapping to map individual client certificates to accounts, or many-to-one mapping to accept a wide range of certificates that meet specific criteria. For more information about mapping client certificates, see IIS online Help. After this is done, you can restrict or allow access to the MSMQ virtual directory by configuring security settings for the corresponding physical directory.

When all the conditions imposed by IIS are satisfied, the sender (SSL client) and recipient (SSL server) create and exchange SSL session keys, which are used to encrypt all packets sent over the SSL connection. For more information about certificates and SSL connections, see IIS online Help.

Access control with HTTPS

For messages sent with the https transport (DIRECT=HTTPS) there are two unrelated levels of authentication used.

Hop to Hop Authentication

Hop to hop authentication is performed on the wire between hops through the use of an ISAPI filter (mqis.dll) installed on the destination IIS Server as follows:

  • The Message Queuing service on hop N-1 authenticates the identity of IIS on hop N via the server certificate installed on the IIS Server.

  • The IIS Server on hop N authenticates the identity of hop N-1 using client certificate mapping. In the absence of client certificate mapping, the IIS Server on hop N sets the identity of the Message Queuing service on hop N-1 to the guest account configured for the IIS Server. The IIS Server on hop N then performs an access check of the specified account against the MSMQ web directory.

Hop to hop authentication is performed before the message ever reaches the MSMQ service on hop N.

Note

Hop to hop authentication is performed per hop, if store and forward director (SFD) redirection is used then each hop may authenticate differently.

End to End Authentication

Once hop-to-hop authentication has been successfully negotiated, the Message Queuing service on the destination computer authenticates the user that sent the message as follows:

  • The destination Message Queuing service checks the message for a signature.

  • If the message is signed then the destination Message Queuing service authenticates the user as the account specified in the message signature.

    Note

    Specify whether a message should be authenticated and what digital signature is used by setting the appropriate value for the PROPID_M_AUTH_LEVEL property.

  • If the message is not signed then the destination computer authenticates the message using anonymous access credentials.

For more information about how users sending authenticated messages over HTTP/HTTPS transport can be validated, see Authenticating HTTP/HTTPS messages.