Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Recently our infrastructure team told our development team that you do not need a certificate for https. They mentioned that the only benefit of buying a certificate was to give the consumer peace of mind that they are connecting to the correct website.

This goes against everything I assumed about https.

I read wikipedia and it mentions you need either a trusted certificate or a self signed certificate to configure https.

Is it possible to configure IIS to respond to https without any certificate?

share|improve this question
6  
You may find that this is just a communication issue. Your server probably has self signed certs ready to go. Incidentally, it's this warning you avoid by using a public trusted certificate: m86security.com/kb/article.aspx?id=13446 THat may be acceptable in your environment or it may not. I'd say it's more than just peace of mind - in a public website it's a sign of professionalism! –  Dan Dec 22 '11 at 12:56
5  
Self-signed certs give you encryption, but it can't protect from man in the middle attacks,since you get the same warnings about invalid or unverified certs for the self-signed as you do for some guy intercepting the traffic, decrypting it, stealing the data, and re-encrypting it to return to the client. –  Bart Silverstrim Dec 22 '11 at 13:20
1  
"Self-signed certs give you encryption, but it can't protect from man in the middle attacks [...]", unless the user can trust those self-signed certificates explicitly by some out-of-band mechanism, which is only realistically possible for a small user base that knows you via such an out-of-band mechanism. Unlikely, indeed. –  Bruno Dec 22 '11 at 17:46
    
Or if they trust it the first time, they'll get warned if it changes in the future. Just like SSH signatures, really. –  mfinni Dec 22 '11 at 18:20
1  
Technically SSL/TLS does not need certificates to secure a communications channel. In fact it SSL/TLS can use other mechanism to secure the channel: pgp certs, username/password, pre-shared keys, or "anonymous" (no authentication at all). Similarly SSL/TLS does not guarantee encryption, there are many different cyphers it can use, including "null" (no encryption at all). And there are similar options for digest authentication. So that's all great, but what programs use any of it: basically none at all, definitely no major server or browser software (they all require certificates). –  Chris S Dec 22 '11 at 18:37

3 Answers 3

up vote 18 down vote accepted

No. You must have a certificate. It can be self signed, but there must be a public/private key pair in place to exchange the session symmetric key between server and client to encrypt data.

share|improve this answer
    
Anonymous Diffie-Hellman, as noted in another answer, did permit a connection without a certificate — but modern OpenSSL versions are usually compiled without any support for ADH. –  Brandon Rhodes Jun 25 at 18:14

In short, no, but there might be subtle cases depending on how you want to deploy the system.

HTTPS is HTTP over SSL/TLS, and you can use SSL/TLS without certificate or with certificates of other types than X.509.

  • Anonymous cipher suites: they can provide encryption, but without authentication. Rather useless as far as security is concerned... To quote RFC 4346: "anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-in-the-middle attacks."
  • Pre-shared keys: it has its own mechanism to verify the remote identity, but the shared nature of the keys brings its own set of problems (in particular limited deployment).
  • Kerberos cipher suites: the client can verify the identity of the server against the Kerberos principal name.

Strictly speaking, the HTTP over TLS specification says the following:

In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.

If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.

In short, it's clearly intended for usage with an X.509 certificate (it clearly references RFC 2459, later superseded by RFC 3280 and 5280: PKIs with X.509 certificates).

There can be an edge case when you're using Kerberos cipher suites. It may make sense to treat the server's Kerberos service ticket could be assume to have the same purpose as the X.509 certificate in usual HTTPS, for the verification of the remote party's identity. It doesn't quite fit within the rules of RFC 2818 (although it might fall under "If the client has external information as to the expected identity of the server, the hostname check MAY be omitted."), but it wouldn't be completely absurd. This being said, I don't think usual browsers support TLS Kerberos cipher suites in general (a number can support Kerberos via SPNEGO authentication, but that's unrelated). In addition, this would also only work in an environment where using Kerberos is suitable.

"[Giving] the consumer peace of mind that they are connecting to the correct website" is actually one of the key requirements for securing the communication between them and your server. Do use a certificate they can verify, with the appropriate naming conventions (RFC 2818 or more recently RFC 6125).

share|improve this answer

You CAN'T use https without any certificate. You need either to buy a trusted certificate or create a self-signed one for testing. Part of configuring your web server to use https is to point it to the correct key files. Of course, this applies to all web servers not only to iis.

share|improve this answer
    
To test whether your OpenSSL can support certificate-less connections, run openssl ciphers and look for an ADH protocol like ADH-AES256-SHA — if such a protocol is present, then you can technically set up a connection without any certificates involved. –  Brandon Rhodes Jun 25 at 18:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.