Replies to This Discussion

Permalink Reply by Myo Aung on November 20, 2007 at 2:49pm

The Internet has opened up new ways for organizations to communicate, both internally and externally. Better communication between employees, vendors, and customers enables an organization to cut costs, bring products to market faster, and build stronger customer relationships. This improved communication requires--at times--transmitting sensitive information over the Internet and intranets. It thus becomes imperative to be able to conduct private, tamper-proof communication with known parties. To bring this about, organizations can build a secure infrastructure based on public-key cryptography by using digital certificates with technologies such as Secure Sockets Layer (SSL). This step-by-step guide discusses how to set up SSL on an Information Services (IIS) computer.

Requirements
The following items describe the recommended hardware, software, network infrastructure, skills and knowledge, and service packs that you will need: • Windows 2000 Server, Advanced Server, or Professional, with Internet Information Services (IIS) version 5.0 and Microsoft Certificate Server version 2.0 installed and configured.
• Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, or Windows Server 2003 Web Edition-based computer with Internet Information Services (IIS) 6.0 and Certificate Services installed and configured.
If the computer that is hosting Certificate Server is not the same computer that has IIS, you need a valid network or Internet connection to the server that is hosting Certificate Server.

Create a certificate request
First, the Web server must make a certificate request. To do this, follow these steps: 1. Start the Internet Service Manager (ISM), which loads the Internet Information Server snap-in for the Microsoft Management Console (MMC). To do this, click Start, point to Programs, point to Administrative Tools, and then click Internet Service Manager or Internet Information Services (IIS) Manager.
2. Double-click the server name so that you see all of the Web sites. In IIS 6.0, expand Web Sites.
3. Right-click the Web site on which you want to install the certificate, and then click Properties.
4. Click the Directory Security tab, and then click Server Certificate under Secure Communications to start the Web Server Certificate Wizard.
5. In IIS 6.0, click Next. If you are running IIS 5.0, go to step 6.
6. Select Create a new certificate and click Next.
7. Select Prepare the request now, but send it later and click Next.
8. Type a name for the certificate. You may want to match the certificate name to the name of the Web site. Now, select a bit length; the higher the bit length, the stronger the certificate encryption. Select Server Gated Cryptography if your users may be coming from countries with encryption restrictions.
9. Type your organization name and the organizational unit (for example, MyWeb and Development Dept). Click Next.
10. Type either the fully qualified domain name (FQDN) or the server name as the common name. If you are creating a certificate that will be used over the Internet, it is preferable to use a FQDN (for example, www.MyWeb.com). Click Next.
11. Enter your location information, and then click Next.
12. Type the path and file name to save the certificate information to, and click Next to continue.

Note If you type anything other than the default location and file name, be sure to note the name and location you choose, because you will have to access this file in later steps.
13. Verify the information that you have typed, and then click Next to complete the process and create the certificate request.

Submit a certificate request
The certificate request that you just created needs to be submitted to a Certificate Authority (CA). This may be your own server with Certificate Server 2.0 installed on it or an online CA such as VeriSign. Contact the certificate provider of your choice and determine the best level of certificate for your needs. There are different methods of submitting your request. Contact the Certificate Authority of your choice to request and receive your certificate. You can create your own certificate with Certificate Server 2.0, but your clients must implicitly trust you as the Certificate Authority. The steps below assume that you are using Certificate Server 2.0 as the certificate provider.

Note The IIS Certificate Wizard will only recognize the Default Web Server template. When you select an Online Enterprise CA, the Authority will not be listed unless the CA is using the Default Web Server template.1. Open a browser and browse to http://YourWebServerName/CertSrv/.
2. In IIS 5.0, select Request a Certificate and click Next. In IIS 6.0, click Request a certificate.
3. In IIS 5.0, select Advanced Request and click Next. In IIS 6.0, click advanced certificate request.
4. In IIS 5.0, select Submit a Certificate Request using a Base64 and click Next. In IIS 6.0, click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
5. In Microsoft Notepad, open the request document that you created in the "Create a certificate request" section. In IIS 6.0, you can also click Browse for a file to insert.
6. Copy the contents of the document. The contents should resemble the following: -----BEGIN NEW CERTIFICATE REQUEST-----
MIICcjCCAhwCAQAwYjETMBEGA1UEAxMKcm9ic3NlcnZlcjELMAkGA1UECxMCTVMx
CzAJBgNVBAoTAk1TMREwDwYDVQQHEwhCZWxsZXZ1ZTERMA8GA1UECBMIV2FzaGl0
b24xCzAJBgNVBAYTAlVTMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALYK4sYDNQ7h
LmSfL0qpIvUfY7Ddw7fNCvDp3rM7z4QqoLhA2c8TkyamqWTBsV0WRHIidf/J6mU4
wN4wrUzJTLUCAwEAAaCCAVMwGgYKKwYBBAGCNw0CAzEMFgo1LjAuMjE5NS4yMDUG
CisGAQQBgjcCAQ4xJzAlMA4GA1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEF
BQcDATCB/QYKKwYBBAGCNw0CAjGB7jCB6wIBAR5aAE0AaQBjAHIAbwBzAG8AZgB0
ACAAUgBTAEEAIABTAEMAaABhAG4AbgBlAGwAIABDAHIAeQBwAHQAbwBnAHIAYQBw
AGgAaQBjACAAUAByAG8AdgBpAGQAZQByA4GJAGKa0jzBn8fkxScrWsdnU2eUJOMU
K5Ms87Q+fjP1/pWN3PJnH7x8MBc5isFCjww6YnIjD8c3OfYfjkmWc048ZuGoH7Zo
D6YNfv/SfAvQmr90eGmKOFFiTD+hl1hM08gu2oxFU7mCvfTQ/2IbXP7KYFGEqaJ6
wn0Z5yLOByPqblQZAAAAAAAAAAAwDQYJKoZIhvcNAQEFBQADQQCgRCWkaXlY2nVa
tbn6p5miPwWfrbViYo0B62wkuH0f7J0nSGcxMnn/6Q/iLEIsgHqFhox5PWCzIV0J
tXKPWrBL
-----END NEW CERTIFICATE REQUEST-------

Note If you save the document with the default name and location, it is located at C:\Certreq.txt.

Note Be sure to copy all of the content just as shown.


7. Paste the contents of the document into the Web form's Base64 Encoded Certificate Request text box.
8. Under Certificate Template, select Web Server or User, and then click Submit.
9. If Certificate Server is set to Always Issue the Certificate, you can access the certificate immediately. To do this, follow these steps:a. Click Download CA Certificate (do not click Download CA Certificate path or Download certificate chain).
b. When you are prompted, select Save this file to disk and save the certificate to your desktop or another location that you will remember. You may now go directly to the "Install the certificate and set up an SSL Web site" section.

Issue and download a certificate
To issue a certificate in Certificate Server, follow these steps: 1. Open the CA MMC snap-in. To do this, click Start, point to Programs, point to Administrative Tools, and then click Certificate Authority.
2. In IIS 5.0, expand Certificate Authority and click the Pending Requests folder. Your pending certificate requests appear in the right pane. In IIS 6.0, expand the server name.
3. Right-click the pending certificate request that you just submitted, select All Tasks, and then click Issue.

Note After you select Issue, the certificate is no longer displayed in this window and folder. It now resides in the Issued Certificate folder.
4. After you have issued (and authorized) the certificate, you can return to the Certificate Servers Web interface to select and download the certificate. To do this, follow these steps:a. Browse to http://YourWebServerName/CertSrv/.
b. On the default page, select Check on a pending certificate and click Next. In IIS 6.0, click View the status of a pending certificate request.
c. Select your pending certificate, then click Next to go to the download page.
d. On the download page, click Download CA Certificate (do not click Download CA Certificate path or Download certificate chain).
e. When you are prompted, select Save this file to disk and save the certificate to your desktop or another location that you will remember.

Install the certificate and set up an SSL Web site
To install the certificate, follow these steps: 1. Open the Internet Services Manager and expand the server name so that you can view the Web sites.
2. Right-click the Web site for which you created the certificate request and click Properties.
3. Click the Directory Security tab. Under Secure Communications, click Server Certificate. This starts the Certificate Installation Wizard. Click Next to continue.
4. Select Process the pending request and install the certificate and click Next.
5. Type the location of the certificate that you downloaded in the "Issue and download a certificate" section, then click Next. The Wizard displays the Certificate Summary. Verify that the information is correct, then click Next to continue.
6. Click Finish to complete the process.

Configure and test the certificate
To configure and test the certificate, follow these steps: 1. On the Directory Security tab, under Secure Communications, note that there are now three available options. To set the Web site to require secure connections, click Edit. The Secure Communications dialog box appears.
2. Select Require Secure Channel (SSL) and click OK.
3. Click Apply and then OK to close the property sheet.
4. Browse to the site and verify that it works. To do this, follow these steps:a. Access the site through HTTP by typing http://localhost/Postinfo.html in the browser. You receive an error message that resembles the following:
HTTP 403.4 - Forbidden: SSL required.
b. Try to browse to the same Web page using a secured connection (HTTPS) by typing https://localhost/postinfo.html in the browser. You may receive a security alert that states that the certificate is not from a trusted root CA. Click Yes to continue to the Web page. If the page appears, you have successfully installed your certificate.

• ▶ Reply

Permalink Reply by Pyae Phyoe Shein on November 20, 2007 at 2:58pm

Thanks for your reply. But, these 2 thread are just for the whole site to make secure layer. My point is to make only login.aspx file to be secure layer, not the whole site.

Thanks in advance.

• ▶ Reply

Permalink Reply by Myo Aung on November 20, 2007 at 3:07pm

Overview
ASP.NET 2.0 Web applications that use Forms authentication use an authentication ticket that is transmitted between Web server and browser either in a cookie or in a URL query string. The authentication ticket is generated when the user first logs on and it is subsequently used to represent the authenticated user as the user sends requests to the application. It contains a user identifier and often a set of roles to which the user belongs. The browser passes the authentication ticket on all subsequent requests that are part of the same session to the Web server.

Failing to properly protect the Forms authentication ticket is a common vulnerability that can lead to the following:

Elevation of privileges. An attacker could elevate privileges within your application by updating the user name or list of roles contain in the ticket prior to posting it back to the server.
Session hijacking. An attacker could capture another user's authentication ticket and use it to access your application.
Eavesdropping. An attacker could look inside a Forms authentication ticket to obtain sensitive role membership details and use this information to attack your application.
To offer protection against these threats, ASP.NET Forms authentication provides the following countermeasures:

Hashed MACs (HMACs). These use either SHA1 or MD5 to provide tamper-proofing. Any changes to the authentication ticket are detected at the server and an exception thrown if it has been modified.
Encryption. Encryption turns the clear text data contained in the Forms authentication ticket into unintelligible cipher text. ASP.NET 2.0 uses AES, 3DES or DES symmetric encryption to prevent anyone from viewing the contents of the Forms authentication ticket.
Session lifetime restrictions. You can use these to reduce the time window in which an attacker can spoof identity by using another user's captured authentication ticket.
Enforced transmission over SSL. You can prevent authentication tickets being transmitted over HTTP connections. This prevents an attacker from being able to view or modify the authentication ticket while it crosses the network.
Summary of Steps
Perform the following steps to protect your application's Forms authentication tickets:

Step 1: Configure
Step 2: Protect Authentication Tickets with SSL
Step 3: Limit Ticket Lifetime
Step 1: Configure
You should ensure that your Forms authentication tickets and encrypted and integrity checked by setting the protection="All" on the element. This is the default setting and you can view this in Machine.config.comments.



Make sure that your application specific Web.config does not override this default setting.

Use SHA1 for HMAC Generation and AES for Encryption
Review the settings to see what hashing algorithm and what encryption algorithms are used. The defaults of SHA1 and AES are recommended. SHA1 is preferred to MD5 hashing because it produces a larger hash size and is therefore considered more secure. AES is preferred to DES and 3DES due to its larger key sizes.

ASP.NET 2.0 defaults to using SHA1 and AES. The following defaults are documented in Machine.config.comments.


validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
decryption="Auto"
validation="SHA1" />

With the default values of "Auto" for the decryption attribute, and "AutoGenerate,IsolateApps" for the decryptionKey, tickets are encrypted with AES symmetric encryption.

The above settings are recommended and should not be changed for single server deployments. For Web farm deployments, you must manually generate key values and ensure they are the same across all servers in the Web farm. For more information about configuring the element and about generating manual keys, see "How To: Configure the MachineKey in ASP.NET 2.0".

Step 2: Protect Authentication Cookies with SSL
If you use cookie-based Forms authentication, to prevent cookies being captured and tampered with while crossing the network, ensure that you use SSL with all pages that require authenticated access and restrict forms authentication tickets to SSL channels by setting requireSSL="True".

To Restrict Forms Authentication Tickets to SSL Channels:
Set this cookie property by setting requireSSL="true" on the element as follows:


requireSSL="true" . . . />

By setting requireSSL="true" you set the "secure" cookie property that determines whether or not browsers should send the cookie back to the server. With the secure property set, the cookie is sent by the browser only to a secure page that is requested using an HTTPS URL.

Partition Your Web Site
To avoid having to use SSL across your entire site, structure your Web site so that the secure pages that require authenticated access are placed in a subdirectory that is separate from the anonymously accessible pages.

Insert VS.NET 2005 Diagram That Shows Structured Site>>

To secure restricted pages with SSL:
Configure the secure folders in IIS to require SSL.

This sets the AccessSSL=true attribute for the folder in the IIS metabase. Requests for pages in the secured folders will only be successful if https is used on the request URL.

Step 3: Limit Ticket Lifetime
Limit the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain access to your application with a spoofed identity. The default timeout for an authentication cookie is 30 minutes. Consider reducing this to 10 minutes as shown below.


timeout="10"
slidingExpiration="True"… />

The slidingExpiration="True" setting ensures that the expiration period is reset after each Web request. With the above configuration this means that the cookie only times out after a 10 minute period of inactivity.

Consider Using a Fixed Expiration Period if You Don't Use SSL

If you do not use SSL to protect the cookie, consider setting slidingExpiration="false" on the element to fix the cookie expiration, rather than resetting the expiration period after each Web request.

Additional Considerations
In addition to the above guidance, consider the following additional items to offer further protection.

Do not persist Forms authentication cookies
Use distinct cookie names and paths
Keep authentication and personalization cookies separate
Use absolute URLs for navigation
Do Not Persist Forms Authentication Cookies
Do not persist authentication cookies because they are stored in the user's profile on the client computer and can be stolen if an attacker gets physical access to the user's computer.

You can specify a non-persistent cookie when you call RedirectFromLoginPage having validated the user's credentials. This is shown below:

Public Sub Login_Click(sender As Object, e As EventArgs e)
' Is the user valid?
If (Membership.ValidateUser(userName.Text, password.Text)) Then
// Parameter two set to false indicates non-persistent cookie


FormsAuthentication.RedirectFromLoginPage(
username.Text,
false)
Else
Status.Text = "Invalid credentials. Please try again."
End If
End Sub

Use Distinct Cookie Names and Paths
Use unique name and path attribute values on the element as follows.


path="/FormsAuth" . . . />

By ensuring unique values for the name and path attributes, you prevent possible problems that can occur when hosting multiple applications on the same server. For example, if you don't use distinct names, it is possible for a user who is authenticated in one application to make a request to another application without being redirected to that application's logon page.

Keep Authentication and Personalization Cookies Separate
Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies. A stolen personalization cookie might not represent a security threat, whereas an attacker can use a stolen authentication cookie to gain access to your application.

Use Absolute URLs for Navigation
Navigating between the public and restricted areas of your site (that is, between HTTP and HTTPS pages) is an issue because a redirect always uses the protocol (HTTPS or HTTP) of the current page, not the target page.

Once a user logs on and browses pages in a directory that is secured with SSL, relative links such as "..\publicpage.aspx" or redirects to HTTP pages result in the pages being served using the https protocol, which incurs an unnecessary performance overhead. To avoid this, use absolute links such as "http://servername/appname/publicpage.aspx" when redirecting from an HTTPS page to an HTTP page.

Similarly, when you redirect to a secure page (for example, the login page) from a public area of your site, you must use an absolute HTTPS path, such as "https://servername/appname/secure/login.aspx", rather than a relative path, such as restricted/login.aspx. For example, if your Web page provides a logon button, use the following code to redirect to the secure login page.

private void btnLogon_Click( object sender, System.EventArgs e )
{
// Form an absolute path using the server name and v-dir name
string serverName =
HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);
string vdirName = Request.ApplicationPath;
Response.Redirect("https://" + serverName + vdirName +
"/Restricted/Login.aspx");
}

Summary
Forms authentication tickets are passed in cookies or URL strings between the browser and server. Failing to properly protect the Forms authentication ticket is a common vulnerability that can lead to elevation of privileges and session hijacking. To protect the ticket, ensure that it is integrity checked and encrypted. Also use SSL to protect those pages in your application that require authenticated access. To limit the amount of time that an attacker has to capture and use an authentication ticket to access your application, consider session lifetime and reduce the lifetime as much as you can in your application scenario.

• ▶ Reply

Permalink Reply by Swe Win Aung on November 21, 2007 at 1:33pm

what about checking with certificate provider? you might bump into corrupted certificate key generated by provider. Sorry, I do not have experienced with IIS. I have only done with sun iws and apache.

at that time, i had an issue that private key database was locked and in the end, it was due to corrupted certificate from provider.

• ▶ Reply

Permalink Reply by Myo Kyaw Htun on November 27, 2007 at 8:56am

Thank Ko Myo Aung for your complete guide.

Please use &lt; &gt; . It will show < > for coding, so everyone can see your html coding. Just a thought.

• ▶ Reply