MSMQ over HTTPS
N Anderton
private$\PRERESLogging we have accessed this through
FormatName=OS:MachineName\Private$\PRERSLogging.
We installed HTTP support and tested the queue again. So far we can access
with the machine name
FormatName:Direct=http://<machineName>/msmq/private$/PRERSLogging
but we have been unable to access it with a DNS name
FormatName:Direct=https://<DNSName>/msmq/private$/PRERSLogging
I have just succeeded in getting this to work with a mapping
<redirection>
<from>http://<machineName>//msmq/private$/PRERSLogging</from>
<to>http://<DNSName>/msmq/private$/PRERSLogging</to>
</redirection>
but this does not work to map a "https" logical address.
We also currently have the "IgnoreOSNameValidation" set to 1.
The messages get stuck in the outbound queue. not the deadletter queue.
The documentation indicates that this should just work without the mapping.
Any ideas what we are missing.
John Breakwell (MSFT)
I'm not sure that is an MSMQ-specific problem.
It's my understanding that an SSL certificate is issued for a particular
machine name.
If you use a DNS alias to browse the web site then the certificate does not
match - the IP address may be the same but the machine name isn't.
Can you browse to a web page on the server using https://<DNSName>/page.htm
?
My Blog covering known HTTP/MSMQ issues:
http://blogs.msdn.com/johnbreakwell/archive/tags/MSMQ+over+HTTP/default.aspx
Cheers
John Breakwell (MSFT)
"N Anderton" <NAnd...@discussions.microsoft.com> wrote in message
news:21F82702-ECB0-4697...@microsoft.com...
> We are trying to get MSMQ working over HTTPS. We have a private Queue set
N Anderton
thought that perhaps the account that MSMQ was running under did not have
sufficient priveldges to verify the SSL Certificate. So far we do not think
this is the issue but since it is still not working I think we are now
questioning our understanding on how any of this should work.
I also noticed that I posted the incorrect mapping that was required to get
the http working. The mapping is
<redirection>
<from>http://<DNSName>/msmq/private$/PRERSLogging</from>
<to>http://<machineName>/msmq/private$/PRERSLogging</to>
</redirection>
John Breakwell (MSFT)
You do not need to worry about the account that MSMQ is running under. If
you think about it, SSL works on the Internet where nobody has any
privileges.
Let's start by checking the SSL part.
Can you browse to a web page on the server using something like
https://<DNSName>/page.htm?
Now the MSMQ part.
You have only provided the mapping you are using for HTTP messages.
What mapping are you using for HTTPS messages?
Your file should look like this:
<Redirections>
<redirection>
<from>http://<DNSName>/msmq/private$/PRERSLogging</from>
<to>http://<machineName>/msmq/private$/PRERSLogging</to>
</redirection>
<redirection>
<from>httpS://<DNSName>/msmq/private$/PRERSLogging</from>
<to>http://<machineName>/msmq/private$/PRERSLogging</to>
</redirection>
</Redirections>
Cheers
John Breakwell (MSFT)
"N Anderton" <NAnd...@discussions.microsoft.com> wrote in message
news:D7DA6AEC-7463-44B3...@microsoft.com...
N Anderton
https://<DNSName>/page.htm?
navigate to that page.
Yes I have tried with the mapping suggested below.
<redirection>
<from>https://<DNSName>/msmq/private$/PRERSLogging</from>
<to>http://<MachineName>/msmq/private$/PRERSLogging</to>
</redirection>
Thanks
Noel
John Breakwell
What is the status of the outgoing queue on the sender? Waiting to connect?
Connected?
Did you have a look at the blog posts I mentioned at
http://blogs.msdn.com/johnbreakwell/archive/tags/MSMQ+over+HTTP/default.aspx ?
Specifically:
"MSMQ messages using HTTP just won't get delivered #8"
"MSMQ messages using HTTP just won't get delivered #13"
which discuss the certificate stores and the certificate revocation list.
Cheers
John Breakwell (MSFT)
http://blogs.msdn.com/johnbreakwell
N Anderton
your list the first time I just did not understand enough. Second time thru
and I am a little clearer, but I still have a couple of questions.
I tried to navigate to the URL of the revocation list and I was blocked by
our coporate internet filter. I followed the knowledge base article to turn
off the revocation check and it started working. But this does not seem like
the correct solution. Which account needs access to this list? How often
does it check it? Most of our applications that will use this are ASP.net
applications so does the account that the app pool runs under need access to
this list?
Thanks for you help.
Noel
John Breakwell
Yes, the correct solution would be to open the corporate internet filter to
allow access to the certificate revocation list. It's ironic that the filter
may be making the network less secure through stopping certificates being
checked.
I don't understand the question about the accounts being used. If the list
is on a remote location on the Internet then it doesn't matter what account
is being used - certificate revocation lists need to be available to any
requester.
N Anderton
about the users that need access, because the filter is based on user groups.
I need to know which account to put into the group that has access to this
web site (the revocation list).
Thanks
John Breakwell
The answer is Everyone. Every single user within the company will
potentially need access to the revocation list to ensure the certificate for
the website is valid.
This isn't an MSMQ-specific issue - Internet Explorer, for example, will
want to check the RCL as well for browsing any of your HTTPS sites and I
expect that will be using the account of the logged-in user.
I don't know what account would be used in the case of MSMQ - the staff that
manage your filter will be best placed to tell you as it should be logged.
If not, it will either be the user account that is running the application
that generates the message in the first place or that of the MSMQ service.
As the MSMQ service is going to be run under a local, not domain, account
the filter will not be able to resolve it - anonymous logon - and so you
will need to have access for Everyone to this particular URL.