Create a Self-Signed Certificate within IIS Express

Question

From my understanding it is in fact possible to create a certificate issued to an IP address. Is it possible to do so within IIS Express?

Please note that this is for testing only.

Edit

People seem to be missing the real meat and potatoes of my question so I have removed the extra details.

Answer 1

Thank you @Bruno for all your suggestions!! Using a separate tool to create the SSL certificate got me going in the right direction.

First I tried the IIS 6 selfssl command-line tool which likely would have worked as well for step one of getting this to work (but I have not tested it after finding my current solution). The first step is creating the certificate and the second step is to bind that certificate to my IP/Port.

1. I used makecert from the Visual Studio Command Prompt to create my cert (this is where I think that the IIS 6 selfssl tool from the IIS 6 Resource Kit should work as well). After creating the certificate I found it under Personal/Certificates using the mmc snap-in console and adding the Certificates snap-in.

   makecert -r -pe -n "CN=0.0.0.0" -b 01/01/2011 -e 01/01/2025 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

2. To bind the cert to my IP/Port I used netsh. ipport should be changed to your IP/Port. appid is a GUID and I don't believe that this matters what you set it to. certhash you can get from the Thumbnail field on the certificate itself but you must remove the spaces in the hash.

   netsh http add sslcert ipport=0.0.0.0:44300 appid={AnyGuid} certhash=YourCertificateThumbprint

Answer 2

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.)

I'm not sure what you generate your certificate with. makecert.exe seems not to be able to generate certificates with SANs, unfortunately.

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.)