This is unlikely to hit many users, but I just bumped into this today.  I'm on
a machine which doesn't have anything in /etc/grid-security.  I have a usercert
in ~/.globus, have created a proxy, but also (oddly) have a hostcert.pem and
hostkey.pem in ~/.globus too.

Here's how globusrun-ws behaves:

If I don't say -self:
$ bin/globusrun-ws -submit -c /bin/date
...
globus_gsi_gssapi: Authorization denied: The name of the remote host (Charles
Bacon 332900), and the expected name for the remote host (bacon.local) do not
match. This happens when the name in the host certificate does not match the
information obtained from DNS and is often a DNS configuration problem.

Okay, that makes sense, my laptop is named "bacon.local".  If I do say -self:

$ bin/globusrun-ws -submit -self -c /bin/date
...
globus_gsi_gssapi: Authorization denied: The name of the remote entity
(/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900), and the expected name
for the remote entity
(/DC=org/DC=doegrids/OU=Services/CN=host/grandcentral.cs.wisc.edu) do not match

Er, what?  Where did the expected name come from?
$ grid-proxy-info -identity
/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900
$ env | grep X509
[nothing]
$ grid-cert-info -file ~/.globus/hostcert.pem -subject
/DC=org/DC=doegrids/OU=Services/CN=host/grandcentral.cs.wisc.edu

Okay, that's where it's getting it from, but I'm surprised it's looking there. 
Let's check if the counter-client behaves the same way:

$ bin/counter-create -s
https://192.168.1.120:8443/wsrf/services/SecureCounterService -m conv
        org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/192.168.1.120" target but received
"/DC=org/DC=doegrids/OU=People/CN=Charles Bacon 332900")]

Right, okay.  (although I dislike the difference between the IP expected by
java and the name expected by C).  So let's give it a -z self:
$ bin/counter-create -s
https://192.168.1.120:8443/wsrf/services/SecureCounterService -z self -m conv
...
 <ns2:ReferenceProperties xsi:type="ns2:ReferencePropertiesType">
  <ns1:CounterKey>9787710</ns1:CounterKey>
 </ns2:ReferenceProperties>

So that worked okay.  We should figure out where the discrepancy comes from,
which behavior is expected, then fix the one that's working differently.

Workaround:  Don't keep a hostcert in ~/.globus while using globusrun-ws -self.
 :-)