As I was saying in this answer :
For SSL/TLS to be secure, you need at least 3 points:
- A suitable cipher suite, and a successful handshake.
- Verifying that the client trust the server certificate (typically, via a known CA in the PKI model).
- Verifying that the certificate belongs to the server the client intended to contact (hostname verification).
The second and third points are enforced by your certificate. You're facing a problem regarding the third point: hostname verification.
Using a self-signed certificate is a substitute for using a certificate issued by a CA (part of a PKI). This tells you whether you can trust the certificate content to be genuine (as asserted by the issuer). By issuing and using a self-signed certificate, you assert its content yourself. Your clients will have to trust explicitly what you're saying. This is fine for small deployments where you can convince the clients to install your self-signed cert as a trusted cert.
Hostname verification is a required step after this. If you check someone's identity using their passport, it's not good enough to check whether it's a genuine passport from a country you recognise: you also need to check that the picture matches the person in front of you. The same applies here: what you want to connect to is given my the host name (or IP address), and it must match the host name (or IP address) in the certificate you're presented with.
Of course, localhost is only ever accessible from the local machine itself, a bit like saying "me". As a server, you need the name in the certificate to be what your clients are going to call you. It's usually better to do this using a hostname rather than an IP address. Note that, according to RFC 2818. if you use an IP address, it also needs to be in the Subject Alternative Name extension (although some browsers will be flexible on that requirement).
(You may also be interested in this answer. Although it's about a Java server, the principles are the same, since the certificate verification is up to the client, which could be in any language.)
EDIT: (You've removed a large part of your initial question, so my answer above might not completely make sense. )
In short, yes, you can generate a certificate that identifies a machine by an IP address.
In theory (RFC 2818 ), the IP address must in the Subject Alternative Names (SAN) extension of your certificate (it would be a SAN of type "IP", not "DNS"). However, in practice, this particular section of the specification is only loosely followed, so you would probably want to have you IP address in the Common Name (CN) of your Subject DN. If the browsers fail to implement RFC 2818 sufficiently, you may even be able to get away with using only CN=your.ip.address in the Subject DN, without having to need a SAN entry. (Java clients seem to be strict on this. but this may not be necessary for your test case.)
In this case, you can generate a self-signed certificate using OpenSSL, for example (see the notes at the bottom of this answer ). If needed, create a PKCS#12 (with extension .pfx or .p12 file from your private key and generated certificate ( openssl pkcs12 -export -in cert.pem -inkey privkey.pem -out store.pfx ). After this, look into configuring the certificate in your .pfx file into IIS Express. You'll have to import the certificate and private key into your certificate store (most likely, double-clicking should trigger the right dialog). Then, use it (as if it came from a CA); depending on how you're configuring IIS, it may have to involve netsh. There seems to be a tutorial here: http://blogs.blackmarble.co.uk/blogs/rfennell/post/2011/03/22/how-to-expose-iis-express-to-external-network-connections-and-use-a-non-self-signed-certificate.aspx (The netsh commands are also listed in this question mentioned by @MrZombie: you'll have to find your self-signed certificate hash by looking into your installed certificates, and adapt the port number according to your setup.)