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

is it compulsory to have a certificate when setting up a https web site on IIS. and also if im hosting a site for which iv already got certificates, when including the certificate i should know the source which issued the certificate? and also if i set it up as a http site will the functionalities work as before? please help as im very new to IIS

share|improve this question

migrated from stackoverflow.com Mar 7 '11 at 3:44

This question came from our site for professional and enthusiast programmers.

    
What does your second question mean? –  SLaks Mar 7 '11 at 3:28
    
i mean if i set it up with out including the certificates just as a http site will the hosted site function properly?as in will i be able to see the site and see it's fuctionalities like it they are supposed to be? –  clb Mar 7 '11 at 3:31
add comment

3 Answers

A server certificate that the client trusts is mandatory for setting up an SSL session. The client can generate a certificate on the fly, but the server must have a certificate with a chain of trust that terminates with a root certificate that is trusted by the client.

Simple TLS handshake (source)

A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:

  1. Negotiation phase:
    • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.
    • The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected.
    • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).
    • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
    • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.)
    • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".
  2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
    • Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
    • The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
  3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
    • The server sends its authenticated and encrypted Finished message.
    • The client performs the same decryption and verification.
  4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.

If you turn off SSL (https), then communicaton between the client and the server will not be encrypted, but your site should function normally.

I say should because there could be hardcoded absolute https urls that are suddenly broken. Also, if the client certificate is used for authentication purposes, then you may not be able to login to the site - this is unlikely because most websites use a username and password mechanism.

share|improve this answer
add comment

HTTPS is built on certificates.

It is impossible to serve an HTTPS site without a certificate, just like it is impossible to serve an HTTP site without a URL.

share|improve this answer
add comment
  1. Is it compulsory to have a certificate when setting up a https web site on IIS?

Yes, without SSL certificate you can not create a https site.

  1. Also if im hosting a site for which iv already got certificates, when including the certificate i should know the source which issued the certificate?

No need. We can just export and import the certificate. As mentioned in below URL,

http://www.digicert.com/import-export-ssl-certificate.htm

  1. Also if i set it up as a http site will the functionalities work as before?

It will work as before but without any secure communication.

share|improve this answer
add comment

Your Answer

 
discard

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