We Keep Coding

Https connection uses wrong certificate

I have C# HTTPS API server running on the local IP address. The idea is to call API methods from different IP address from the same subnetwork and authenticate using certificate. So, I issued self-signed CA certificate and client certificate. When I run application on localhost everything works well. But when I issued new certificate for IP address I use, the app runs using localhost certificate and client shows me that certificate is not trusted. I added test domain to the hosts file and linked it to my IP address - but when I issued CA certificate for this domain browser opens endpoints using localhost certificate.
How to tell .NET application which certificate to use? Why even after I added test.com domain to the hosts file and issued CA cert for that domain, when I run application and open in browser test.com, it opens my app but shows cert for the localhost and tells that connection is not trusted?

Shall I have client certificates for consumers of my REST API?

I have a REST API which uses JWT bearer authentication over HTTPS. SSL certificate is installed on the web server hosting my REST API. Do I need to provide client certificates to different applications(users) who want to consume my API, to have a handshake between their server and my server using the client certificate which i provide them.
I tried calling my HTTPS REST API which I developed in C# from a python script running locally from my machine but I had to specify the verify flag to False or ssl.CERT_NONE for the call to succeed
import requests
requests.get('some https url', verify=False)
I know we can also use self signed certificates. I am worried about Man in the Middle attacks if they call my endpoint with verify=False and If someone tries to use my API in his app which is in production over https do I need to give him the client certificate for handshake or his app would be able to call my https api endpoint without me specifically providing a client certificate.
I tried to take some leads from this question but it doesn't explain how different users whose apps are trying to call my endpoint over https, will be able to perform a handshake with my rest api
Any guidance would be highly appreciated.

Quick answer: keep your private key file safe and you wont have any problems.
The long answer has to do with explaining asymmetrical encryption and how its implemented in a TLS handshake. When a client opens a HTTPS connection with your server a series of requests are sent back and forth:
Client sends HELLO
Server sends HELLO back including the servers SSL certificate
Client verifies the certificate with the certificate authority
The client sends back a random string of bytes encrypted with the servers public key
The server decrypts the string using the private key
After the final step a session is created between the client and server. In order for a man-in-the-middle attack to be successful the "man in the middle" needs to have your private key and proxy every action just described back to your server, otherwise one of the steps will fail and the client will get that "SERVER UNVERIFIED" error in their browser warning them that the connection is not secure.
This is a pretty brief explanation of the process, you can do some more reading here

WCF Servcie only worked on local computer of IIS

I created a website on IIS at 192.168.0.163, and published a wcf service application on it, I can get wsdl of service through hostname hostname:port/Service.svc?wsdl and ip address 192.168.0.163:port/Service.svc?wsdl, but hostname.domain.com:port/Service.svc?wsdl not work, on another computer in same domain.
At the end of wsdl, I found the service address is ws://hostname.domain.com:port/Service.svc.
In client, I added service reference by vs2015, in app.config the service address also is ws://hostname.domain.com:port/Service.svc, and I can only connect to service from local computer which IIS stays, calling from another computer will cause a exception:
The remote endpoint requested an address for acknowledgements that is
not the same as the address for application messages. The channel
could not be opened because this is not supported. Ensure the endpoint
address used to create the channel is identical to the one the remote
endpoint was set up with.
If I change address to hostname:port/Service.svc or 192.168.0.163:port/Service.svc, then I faulted to access the service from both computers with same error.
Close firewall can't solve the problem.
How to make this work?

Solved after add hostname in IIS bindings.

WCF and Wildcard Certificates with NetTcp binding

I have a self hosted WCF service using a NetTcp binding and TransportWithMessageCredential security with a wildcard cert (*.company.com) as the service certificate.
The client address of the server is (ServerName.company.com) I get the following error when a service call is made:
Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was 'ServerName.company.com' but the remote endpoint provided DNS claim '*.company.com'. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity '*.company.com' as the Identity property of EndpointAddress when creating channel proxy.
Is this actually possible? Any help is appreciated.

Using SSL with a .net remote endpoint without IIS

I have setup a vanilla .net remote endpoint. It is behind a load balancer that handles SSL traffic so all the server side endpoint sees is plain old TCP traffic. The client configuration needs to be set up to connect to the load balancer over SSL.
The whole point of this exercise is to remove IIS from the technology stack.
What should the client configuration be? or is this even possible?