Using HTTPS in Message Queue

[PTH]

Having problems sending messages to a msmq server via https. To keep it
simple for now I'm just sending a message from a machine in the same domain
on the same LAN.

I can send messages via http but not https. Have created a temp server
certificate and trusted it on the sending server. I can connect to the
default website via https but whenever I send a message it sits in the
outgoing queue saying waiting to connect. Have turned logging on in IIS and
cannot see anything in the log file indicating a connection is being made. I
have read through the 2 microsoft whitepapers on http/https msmq'ing. I'm
starting to pull my hair out now. I think it may be around certificates
where the problem lies but need some advice on how to troubleshoot as msmq is
rubbish for giving debug information back.

If I connect to the server msmq virtual directory I get the 501/505 error as
expected.

I'm not going through any firewalls, routers, etc so just using the
computername e.g.

https://servername/msmq/testqueue

I'm only using a server certificate (no client certificates). Have not done
anything with persmissions as I assume I dont need to and also have created
no mapping xml files as again I assume I dont need to on above setup.

Queue John (no pun intended)......

[John Breakwell]

Hi PTH

"Queue John" :-)

1 Make sure your IIS logs are set to include MSMQ:

"Troubleshooting MSMQ over HTTP - nothing in the web server log files?"
http://blogs.msdn.com/johnbreakwell/archive/2009/10/21/troubleshooting-msmq-over-http-nothing-in-the-web-server-log-files.aspx

2 Certificate Authority needs to be in "Local Computer" store:

"MSMQ messages using HTTP just won't get delivered #13"
http://blogs.msdn.com/johnbreakwell/archive/2008/04/24/msmq-messages-using-http-just-won-t-get-delivered-13.aspx

3 Can the client contact the Certificate Revocation List?

"MSMQ messages using HTTP just won't get delivered #8"
http://blogs.msdn.com/johnbreakwell/archive/2008/01/10/msmq-messages-using-http-just-won-t-get-delivered-8.aspx

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message
news:BF3FC2AB-860C-46F3...@microsoft.com...

[PTH]

Hi John,

Thanks for the reply. I managed to get it going in the end. Think I was
using the wrong type of certificate. However, those articles are useful to
know.

The next step is to try and use it across forests. If I'm connecting to a
server thats in another domain and has network address translation can I
still use the server name in the destination queue format or will I have to
use the domain name and create and xml mapping file on the msmq server.
Currently the certificate name is the name of the server. If I use the
domain name for the queue format name then will I need a new ccertificate to
match the domain name?

Thanks again for your help

"John Breakwell" wrote:

> .
>

[John Breakwell (MSFT)]

Hi PTH,

There are two different operations going on.

1 The establishment of an SSL connection (non-MSMQ)
2 The delivery of messages (MSMQ).

If you can use Internet Explorer to connect to the server over SSL using the
a particular server name then MSMQ should be able to do likewise. Basically
get it all working with IE (where the troubleshooting is propbably easier)
and then test with MSMQ.

The mapping file will only be necessary if MSMQ on the web server doesn't
think the message is for itself. You can use a computer name or a FQDN -
both should work.

Probably best to get it working with HTTP first and then configure a
certificate to match the server name you used to then get HTTPS to work.

Note - I don't expect NAT to work with transactional messages. The
acknowledgements can't make the return trip on a different network
connection.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:4DF3918C-9F53-423D...@microsoft.com...

[PTH]

Hi John,

Thanks for that. It confirms what I thought but its not always clear from
the microsoft documentation ;-)

The only thing I'm not sure about which you might be able to advise on best
practive. If we have a company domain say www.company.com which has the
usual webservers for corporate stuff. Do we have to put message queue on
that to forward it onto the correct message queue server within the corporate
network or should we register a new domain and point that straight to the
application/https msmq server. I ask this as I'm not to sure if the customer
will be to keen to install message queue on their company web servers.

If we specify the server in the queue name, e.g.
www.company.com\msmqserver\msmq\testqueue would we still need a mapping file
on the company.com web server?

Finally if www.company.com resolves to the acutal web server for the
destination message queue would we still need a mapping file. I thought it
would but now I'm not too sure from your last comment below or did than only
apply if using the computername, e.g. servername or servername.company.com.

I assume if using servername.company.com for the queue path then this would
need to be the name of the certificate and not just company.com?

Thanks yet again.

P.S> Why don't Microsoft do a MSMQ course?

"John Breakwell (MSFT)" wrote:

> .
>

[John Breakwell (MSFT)]

Hi PTH,

MSMQ on the client needs to resolve the IP address of a web server running
MSMQ so it can send messages to it.
At this point the issue is a standard IIS one - can the server be reached
from a machine on the Internet?
If your MSMQ application server cannot be reached by an Internet client then
you will indeed require a forwarding webserver (also running MSMQ) for the
incoming MSMQ messages.
How the customer provides that forwarding resource will affect your
requirement for mapping files.

The mapping file for incoming messages is necessary when the address on the
message does not match the machine receiving them.
This can be if the receiving machine is the right destination but has a
different name to the message's address or if the destination is located
elsewhere.
There's no "best practice" as such - you just create a mapping file that
matches your requirements.

"If we specify the server in the queue name, e.g.
www.company.com\msmqserver\msmq\testqueue would we still need a mapping file
on the company.com web server?"

That isn't a valid server name. "www.company.com" is the webserver name;
"msmq" is the webserver virtual application/directory; "testqueue" is the
public queue name.
Anything that breaks this format will prevent MSMQ delivering messages.
You would need to send to one of the following examples:

msmqserver.company.com\msmq\testqueue without a mapping file
server.company.com\msmq\testqueue with a mapping file to local msmqserver
www.company.com\msmq\testqueue with a mapping file to remote msmqserver

There are obviously a range of other possibilities but they all follow the
same basic patterns.

"Finally if www.company.com resolves to the actual web server for the

destination message queue would we still need a mapping file."

If the actual machine name is WWW and the machine is a member of the
Company.com domain then you won't need a mapping file.
If www.company.com is just a DNS entry and the webserver is really called
WebServer7 in the Production domain then you would.

"I assume if using servername.company.com for the queue path then this would
need to be the name of the certificate and not just company.com?"

I'm not an expert on SSL certificates but I believe that the certificate
requires the server name in it. I would recommend checking IIS resources for
clarification.

"Why don't Microsoft do a MSMQ course?"

Demand, cost, budget - the usual suspects.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:4CA44A54-BCC8-44B1...@microsoft.com...

> Hi John,
>
> Thanks for that. It confirms what I thought but its not always clear from
> the microsoft documentation ;-)
>
> The only thing I'm not sure about which you might be able to advise on
> best
> practive. If we have a company domain say www.company.com which has the
> usual webservers for corporate stuff. Do we have to put message queue on
> that to forward it onto the correct message queue server within the
> corporate
> network or should we register a new domain and point that straight to the
> application/https msmq server. I ask this as I'm not to sure if the
> customer
> will be to keen to install message queue on their company web servers.
>
> If we specify the server in the queue name, e.g.
> www.company.com\msmqserver\msmq\testqueue would we still need a mapping
> file
> on the company.com web server?
>

> Finally if www.company.com resolves to the actual web server for the

[PTH]

Hi John,

We have now setup our environment to test using domain names and coming in
over the internet so its more realistic but now we can't even get http
messages working, never mind https which is the ultimate goal.

Our environment is:

A XP client sending messages over internet 'ClientA'.
A 2003 server called 'mqserver' on its own domain 'internal.com' in our DMZ,
it's also a DC as well as the web/msmq server.

We have a 'www.domain.com' registered to an IP address on our firewall and
we have a static mapping for this ip address to the 'mqserver's physical IP
address. We also have a certificate for www.domain.com but we've not yet got
to this stage.

I can view the default website from the remote client e.g.
http://www.domain.com, but when I send a message over http it stays on the
outgoing queue in inactive/waiting to connect state. If I try accessing
http://domain.com/msmq from the remote client I get a http 500 - internal
server error. I would expect the 501/505 error, is this correct or a red
herring. Using the internet facing IP address instead of the domain name
gives the same result. Even if I'm on the actual server when I access the
http://www.domain.com/msmq or use the local IP address I get the 500 error.
If I use the http://localhost/msmq then I get the 501/505 error.

I have a mapping file on the 'mqserver' that looks like this.

<Redirections>
<redirection>
<from>http://www.domain.com/msmq/test</from>
<to>http://mqserver/msmq/test</to>
</redirection>
</Redirections>

The sending application is sending the message in the format
DIRECT=http://www.domain.com/msmq/test.
I have logging on the msmq virtual directory and don't seem to see a
connection being made from the remote client. Have you got any pointers as
I've racked my brain and struggling to see the answer. I'm guessing either a
DNS issue on our test environment although I can resolve www.domain.com on
the server and the remote client or could it be because the server is in a
different domain ('internal.com') to 'domain.com' which is used to resolve
the remote client to the server. I was expecting once we were able to see
the http website remotely it would probably be easy to get working, :-(

Obviously the above is not the actual domain names, etc as I don't want to
post them on a public forum.

Many thanks as usual ;-)

"John Breakwell (MSFT)" wrote:

> .
>

[PTH]

Hi John,

Apologies, just checked the IIS logs again and it is getting a post entry in
so I assume the problem is not IIS but the passing of the post to MSMQ. I've
been through your http blogs but still no joy.

I've checked the msmqinst.log which seems okay, no errors.
Servername is less than 15 chars
Permisisons to the website/virtual directory are okay for the anonymous
user. Even tried it with the administrator as the anonymous user.
The messages are only small so shouldn't be a timing issue.

Is there away of reading the msmq log file without having to raise a support
case?

[John Breakwell (MSFT)]

Hi PTH,

"If I use the http://localhost/msmq then I get the 501/505 error."

So this at least confirms MSMQ/HTTP is up and running.
This test is usually a good/simple one to check functionality although, as
you've found, it doesn't help with fault diagnosis.

You mention that this server has multiple IP addresses.
If you Ping Localhost it will probably have a different IP address to when
you Ping mqserver.

Do you have a HOSTS file with extra entries?
If so, replace it with a clean one.
The MSMQ ISAPI application itself performs some name lookups and any errors
can cause a 500 in a similar (but not identical) fashion to the problem
reported here
http://blogs.msdn.com/johnbreakwell/archive/2006/09/15/msmq-messages-using-http-just-won-t-get-delivered.aspx.

If this is urgent then I would recommend raising a support call with
Microsoft so an engineer can look at the MSMQ log files.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:C32489A2-71E3-4D73...@microsoft.com...

[PTH]

Hi John,

Thanks for the reply. I managed to fix it just after sending the post. I
installed wireshark and noticed I was getting the internal server error after
the msmq post so I was convinced I needed to sort this first. I had a look
around the system and noticed an entry in the hosts file for the
www.domain.com like you have just mentioned. It was pointing to the correct
address but I removed it anyway as I put this in before I got the DNS setup
correctly. Hey presto all started working after. Can now send http and
https messages across the internet :-). I'm currently changing the server to
hardend message queue and using it as a SFD server to send messages to
another message queue server within the internal network. Is this the
recommended way for making the solution more secure? After this I may try
introducing client certificates to improve authentication security further so
more posts may follow ;-)

Thanks again for you help so far.

[PTH]

Hi John, why is nothing in msmq straight forward?

I've pointed my mapping on the mqserver to map to another application mq
server on a internal network in another domain say 'domain2.com'. I can send
http messages from the orginal mqserver to the new server using the FQDN e.g.
appmqserver.domain2.com\msmq\test. I can also access the msmq webpage from
the orginal server to the new server and get the 501/505 error so everything
looks okay from a IIS/MSMQ point of view but the messages are not appearing
on the test queue on appmqserver. The mapping file I now have on the
original msmq server which is now acting as a SFD server looks like this:

<redirections xmlns="msmq-queue-redirections.xml">

<redirection>
<from>http://www.domain.com/msmq/test</from>

<to>http://appmqserver.domain2.com/msmq</to>
</redirection>
<redirection>
<from>https://www.domain.com/msmq/test</from>
<to>https://appmqserver.domain2.com/msmq</to>
</redirection>
</redirections>

On the new appmqserver server I have the following mapping file:-

- <redirections xmlns="msmq-queue-redirections.xml">
- <redirection>
<from>http://www.domain.com/msmq/test</from>
<to>http://appmqserver.domain2.com/msmq/test</to>
</redirection>
- <redirection>
<from>https://www.domain.com/msmq/test</from>
<to>https://appmqserver.domain2.com/msmq/test</to>
</redirection>
</redirections>

I can see post entries on the sfd server in the IIS logs but nothing on the
IIS log on the appmqserver. Should I ? I was expecting too.

Any pointers again?

Why can't Microsoft publish a tool for reading the msmq log so we can have a
chance of debugging these problems :-(

I don't have to change anything in the registry do I to make it become an
SFD server?

[John Breakwell]

Hi PTH

So HOSTS file weirdness in the end.

"I'm currently changing the server to hardened message queue and using it as

a SFD server to send messages to another message queue server within the
internal network. Is this the recommended way for making the solution more
secure?"

Sounds like a good idea - the MSMQ messages do not spend any time on the SFD
server where they could potentially be accessed from the Internet (unless
the final destination is offline when the messages would remaim in the
outgoing queue). And even if the messages were waiting in the outgoing
queue, MSMQ is not listening on any ports to allow any unwanted intrusion.
MSMQ over HTTP doesn't allow for remote receiving of messages so these
messages should be protected. An intruder would have to get access to the
file system and copy the System32\msmq\Storage directory to read the message
contents. And if an intruder can do that then you have more serious issues
to worry about :-)

Hardened MSMQ Mode
http://msdn.microsoft.com/en-us/library/ms703237(VS.85).aspx

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:8F2EC8E9-75E0-4485...@microsoft.com...

[PTH]

Hi John,

An update to my earlier post in getting SFD to work. From wireshark I could
see I was getting the forbidden error which enabled me to work out that the
SSL had been left ticked on the SFD server. I'm now getting a post on the
appmqserver iis log but in wire shark I can see its responding with a
http/1.1 400 bad request. I'm sure its something to do with the domain
name/dns setup we have. If forwarding to a machine in a different domain
should we be doing something different. e.g. domain.com resolves to the SFD
server, is this correct? the end msmq server is actually on domain2.com.
See my previous post for the mapping files I'm using.

"John Breakwell" wrote:

> Hi PTH
>

[John Breakwell]

Hi PTH,

I think "classic" MSMQ is reasonably straightforward. MSMQ over HTTP, I
agree, could be easier - some mapping file generation wizards, for example,
would be handy.

The file on the SFD server doesn't specify a queue to deliver to.
It won't pick up the original queue name and dynamically append it.

<from>http://www.domain.com/msmq/test</from>
<to>http://appmqserver.domain2.com/msmq</to> <<< missing queue name

"Why can't Microsoft publish a tool for reading the msmq log so we can have
a chance of debugging these problems :-("

The product group decided that the contents of the MSMQ logging contains too
much information about the internal workings, such as undocumented methods
and functions, which could be exploited.
Hopefully this will change in the future but at present I am not aware of
any plans to change this policy.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:EA14C48C-EE1C-4CDC...@microsoft.com...

[PTH]

Hi John,

I did it like that as that how it shows how to do it in the msmq http
deployment scenario's white paper. I assumed as it was just forwarding it on
it sends any queues to the msmq remote msmq server and the mapping on there
maps the correct queues. Anyway, I added the test queue to the mapping file
on the sfd server and it still doesn't work. Still getting the http 400 bad
request response as per my previous post.

[PTH]

Hi John,

I've just realised that you meant the application server. I rechecked and
noticed the queue missing. I thought I had put the queue on that server so
assumed you meant the sfd. Its now working so thanks again and now trying
https with the queue forwarding.

[John Breakwell]

Hi

You are correct - the examples in the White Paper do indeed show that you
don't need to specify the full queue name. My error.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:3595ADB6-D114-4A64...@microsoft.com...

[John Breakwell]

Hi

Glad you got things working.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message

news:F96384F6-FC07-44E2...@microsoft.com...