cannot invoke webservices

As a part of SharePoint migration from 2010 to 2013 I was working on moving the webservices from dev to QA. Initially I thought of testing  few defaults like GetAccountName , GetSiteUsers but when I try to invoke I got the below error.

System.ServiceModel.EndpointNotFoundException: The message could not be dispatched because the service at the endpoint address ‘net.pipe://localhost/s4u/022694f3-9fbd-422b-b4b2-312e25dae2a2’ is unavailable for the protocol of the address.

Below are the steps I tried to resolve

  1. killed SMSSvcHost.exe process and then restarted Net.Tcp Listener Adapter service
  2. Reset IIS

Above steps did not help me but it did help others on the net.

Mine was SharePoint specific issue and SharePoint 2013 was claims only so I looked in the services on the central admin and saw that claims to widows token service was not running . I started this and my web services started working.

 

 

SSL

I was tasked to convert few http web sites to https and I took a long journey in to the world of secure socket layer and wanted to share what I learned. I will be quoting a lot in this article as there is plenty of info already out there. This article is just scratching the surface of SSL/TLS.

Communication travels in clear text with http protocol so for all the valid reasons it is sensible to convert it to https in which data in encrypted.

First of all you need a certificate to make an SSLconnection. Please read through the following links to understand a bit about certificates, https://www.verisign.com/en_US/website-presence/website-optimization/ssl-certificates/index.xhtml ,  https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/ .

Once you get a certificate from a trusted CA (certificate authority) then your client have the ability to trust the certificate or atleast can go through the process of trusting. You have to import the certificate in your web server, in my case it is IIS. For steps to do this check out https://technet.microsoft.com/en-us/library/cc732785(v=ws.10).aspx.

Now you need to create a https binding. Please check out http://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis . This link also explains about certificate import and gives you other related info.

At this point if your firewall is set up to accept SSL traffic then you should be able to access the sire using https.

What happens when the communication actually starts.

Say your sitting in starbucks unsecured network and accessing your newly created https site. The first thing the client does is a handshake with the server. Client site authentication follows below steps

  1. The client sends the server the client’s SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
  2. The server sends the client the server’s SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client’s certificate.
  3. The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.
  4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server’s public key (obtained from the server’s certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
  5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client’s own certificate to the server along with the encrypted pre-master secret.
  6. If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
  7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
  8. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
  9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
  10. The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
  11. This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

During the SSL handshake, the server sends the client a certificate to authenticate itself. The client uses the certificate to authenticate the identity the certificate claims to represent. An SSL-enabled client goes through these steps to authenticate a server’s identity:

  1. Is today’s date within the validity period? The client checks the server certificate’s validity period. If the current date and time are outside of that range, the authentication process does not go any further. If the current date and time are within the certificate’s validity period, the client goes on to step 2.
  2. Is the issuing Certificate Authority (CA) a trusted CA? Each SSL-enabled client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to step 3. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
  3. Does the issuing CA’s public key validate the issuer’s digital signature? The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA, or if the CA certificate’s public key doesn’t correspond to the private key that was used by the CA to sign the server certificate, the client does not authenticate the server’s identity. If the CA’s digital signature can be validated, the client treats the server’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client’s responsibility to take step 4 before it takes step 5.
  4. Does the domain name in the server’s certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address that is specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a “Man-in-the-Middle Attack.” Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names do not match. If the server’s actual domain name matches the domain name in the server certificate, the client goes on to step 5.
  5. The server is authenticated. The client proceeds with the SSL handshake. If the client does not get to step 5 for any reason, the server that is identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.

What to watch:

  1. Https will add extra stress on the server so be mind full of resources.
  2. It will breaks the cache to through testing is required.
  3. Be mind full of relative links on your site and make sure all these are changed to https.
  4. check out https://www.quora.com/Are-there-any-disadvantages-to-using-HTTPS-instead-of-HTTP , https://blog.nexcess.net/2014/09/03/the-pros-and-cons-of-implementing-ssl-https/ .

Ref:

https://support.microsoft.com/en-us/kb/257587

https://support.microsoft.com/en-us/kb/257591

http://robertheaton.com/2014/03/27/how-does-https-actually-work/