Tag Archives: X509

XP and the undefined Name Constraints

1 Reply

So Qualified Subordination is super important, it’s what really allows us to implement Least Privilege in PKI hierarchies.

This concept is implemented in Windows XP as of SP3 because there was a back-port of the Windows Vista certificate chain validation logic included in SP3.

With that said there is at least one difference between VISTA, Windows 7 and Windows 8 chain validation logic in the way Name Constraints is processed.

More precisely once it sees a name constraint applied to a certificate it requires that only the names and scope of names expressed in the Name Constraint extension are present in the certificate.

For example, lets say I restrict a CA to issue only for the DNS domain of example.com, once this is put in the certificate I can no longer include “O=Example Company Name” in the subject of the certificates issued by that CA.

If I want the CA to be able to include that organization name in the certificates it issues I have to express that using the DirectoryName constraint.

This is not compliant with the RFC and was later changed so VISTA, Windows 7 and Windows 8 do not behave this way.

That said you can change the behavior in XP by tweaking the following registry key:

HKLM\Software\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots

This is a bitmask represented as a REG_DWORD, it is defined in WinCrypt.h as but the flag following definitions will tell you how to tweak this one part:

#define CERT_PROT_ROOT_FLAGS_VALUE_NAME L”Flags”

// Set the following flag to disable checking for not defined name

// constraints.

//

// When set, CertGetCertificateChain won’t check for or set the following

// dwErrorStatus: CERT_TRUST_HAS_NOT_DEFINED_NAME_CONSTRAINT.

//

// In LH, checking for not defined name constraints is always disabled.

#define CERT_PROT_ROOT_DISABLE_NOT_DEFINED_NAME_CONSTRAINT_FLAG 0x20

You could deploy this behavior via group policy if you did not want the behavior, it’s probably easier to just include the names you are willing to let the CA issue to but changing the behavior in this way in an option for some.

Hope this helps,

Ryan

Updated my script for Qualified Subordination testing

1 Reply

I did some testing with ECC and SHA2 today and as such decided to update my script for testing Qualified Subordination to make it easy to get certificates that use these algorithms.

There are now several configurable variables in makepki.bat:

  • key = possible values include RSA or ECC
  • rsasize = possible values include 1024,2048,4096
  • eccsize= possible values include secp256r1,secp384r1,secp521r1
  • hash = possible values include sha1,sha256,sha384,sha512

With these its very easy to get chains to do testing with that include these algorithms, have fun.

Ryan

Using ECC keys in X509 certificates

Leave a reply

Recently the CAB Forum published a document called the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates.

This document was authored by both browsers and public CAs and is used by the browser vendors to mandate what minimum technical requirements need to be met for inclusion into their “Root Programs”.

One of the changes specified in this document is that subscriber certificates (aka SSL certificates) containing RSA keys must have a bit length of 2048. This is a change for a lot of CAs (GlobalSign had made this change some time ago) one that has implications to server operators.

Just take a look at the Crypto Plus Plus Benchmarks to see how much more expensive 2048 bit RSA. For most users this additional computational cost won’t be an issue but in some cases customers may need to increase the computing power they allocate for SSL establishment.

But what alternatives do you have? Well there is one, certificates with ECC keys; using these have the potential to significantly decrease the computational costs for SSL negotiations (even over your old 1024bit RSA certificate) but they come at a significant penalty – compatibility.

ECC was not supported in Windows until VISTA which was released in 2009, this basically means 100% of the XP clients out there (around 29% of the browsers on the internet as of July 2012) would be unable to establish a session with your website if you switched exclusively to ECC.

This is important for more than just Internet Explorer users since even Chrome and Safari use CryptoAPI for certificate validation when on Windows.

This would mean these users would see something like this:

 

That is pretty scary, so how long until we can use this more broadly? It’s hard to say there is a good article titled “The developers guide to browser adoption rates” that sheds some light, that and the historic gs.statcounter.com results. Based on these unless there is a sudden change (which is possible these machines are getting pretty old) I would assume that we have around 4-5 years of XP out there yet.

Hope this helps,

Ryan

Using SHA2 based signatures in X509 certificates

6 Replies

It’s been an exciting decade for cryptography; as a result we see smaller key sizes and weaker algorithms getting deprecated.

One driver of such things is the U.S. Federal Government, specifically NIST.

One example of this would be NIST Special Publication 800-131A which disallows the use of SHA1 after December 2013. What this means is if you are in the U.S. Federal Government or you work with them you may have to revise your technology strategy to use SHA2 in its place.

But what if you don’t have any policy mandate forcing you to do this switch? Well it’s a good idea but it has consequences too, namely compatibility.

You see SHA2 was published in 2001 so anything produced before then will not support it. The most notable example is Windows XP which as of July 2012 has about 29% presence on the Internet.

This is important for more than just Internet Explorer users since even Chrome and Safari use CryptoAPI for certificate validation when on Windows.

The good news is that XP SP3 which was released in 2008 added support for this new suite of hash algorithms, that begs the question how many of those XP machines have XP SP3?

Unfortunately I don’t have any public references that can answer this question but let’s that 85% of all XP machines on the Internet have gotten this update (I have good confidence in this number) that means that 15% of those 29% would not be able to connect to your server over SSL if you used SHA2.

This would mean these users would see something like this:

 

 

That is pretty scary, so how long until we can use this more broadly? It’s hard to say there is a good article titled “The developers guide to browser adoption rates” that sheds some light, that and the historic gs.statcounter.com results. Based on these unless there is a sudden change (which is possible these machines are getting pretty old) I would assume that we have around 4-5 years of XP out there yet.

Hope this helps,

Ryan

How to get your own OID arc

Leave a reply

X509 uses Object Identifiers (OIDs) to uniquely identify things, for example one assigns a OID to their Certificate Policy Statements (CPS) so that it is possible to programmatically detect if a certificate meets a specific policy.

OIDs are managed as a namespace, this prevents “collision”. As such one needs to request an OID be assigned to them.

The “arc” part comes when you get your OID, you can assign any number you want at the end of your OID. For example, one might be assigned 1.1.1.1 and decide to “break” it up into chunks as follows:

  1. 1.1.1.1.2 – Documents
  2. 1.1.1.1.3 – Certificate Extensions
  3. 1.1.1.1.4 – Resource Identifiers

Underneath each of these you would assign unique numbers by appending a new number, for example 1.1.1.1.2.1 might be your CAs Certificate Practice Statement (CPS).

So how do you get one of these OIDs then? That’s easy it’s Internet Assigned Numbers Authority (IANA) who assigns these, they call them Private Enterprise Numbers. Getting one is easy enough just fill out a web application form. To do that you will only need 7 pieces of information, these include:

  1. Organization Name
  2. Organization Address
  3. Organization Phone
  4. Contact Name
  5. Contact Address
  6. Contact Phone
  7. Contact Email

Remember the idea is that the information you provide here will be used for people to reach you if they want to ask questions about these things you have uniquely identified so choose the values wisely.

It can take up to 60 days to get one of these (although usually the application is processed in about one week).

Once you got the object identifier, you should register the code on the site www.oid-info.com and/or www.alvestrand.no in this way will be easily accessible by those who are seeking information about the owner of object identifier.

Hope this helps.

Ryan

Revocation repositories, IPv6 support, message size, and performance

9 Replies

So the last few weeks I have spent a reasonable amount of time looking at performance and networking related problems associated with revocation repositories. I still have some additional work to do but I figured I would capture some of my findings in a quick post.

CRL repositories and IPv6
CA Host Supports V6
GlobalSign crl.globalsign.com Yes
Comodo crl.comodoca.com No/Sometimes
CyberTrust sureseries-crl.cybertrust.ne.jp No
Symantec/GeoTrust EVSSL-crl.geotrust.com No
Symantec/VeriSign EVIntl-crl.verisign.com No
DigiCert crl3.digicert.com No
StartSSL crl.startssl.com No
TrustWave crl.securetrust.com No
TrustCenter crl.ix.tcclass3.tcuniversal-i.trustcenter.de No
GoDaddy crl.godaddy.com No
Entrust crl.entrust.net No
Certum crl.certum.pl No

* IPv6 Capability was checked via http://ipv6-test.com/validate.php

 

OCSP repositories and IPv6
CA Host Supports V6
GlobalSign ocsp.globalsign.com Yes
COMODO ocsp.comodoca.com No
GoDaddy ocsp.godaddy.com No
DigiCert ocsp.digicert.com No
StartCom ocsp.startssl.com No
TrustCenter ocsp.tcuniversal-I.trustcenter.de No
TrustWave ocsp.trustwave.com No
Enstrust ocsp.entrust.net No
Symantec/GeoTrust ocsp.geotrust.com No
Symantec/VeriSign ocsp.verisign.com No
CyberTrust sureseries-ocsp.cybertrust.ne.jp No
Certum ocsp.certum.pl No

* IPv6 Capability was checked via http://ipv6-test.com/validate.php

 

CRL Size
CA CRL Size # Entries
Certum http://crl.certum.pl/evca.crl 862 7
Symantec/Geotrust http://EVSSL-crl.geotrust.com/crls/gtextvalca.crl 720 12
Cybertrust http://sureseries-crl.cybertrust.ne.jp/SureServer/2021_ev/cdp.crl 1742 17
GlobalSign http://crl.globalsign.com/gs/gsextendvalg2.crl 1114 18
TrustWave http://crl.securetrust.com/STCA.crl 2158 65
StartSSL http://crl.startssl.com/crt4-crl.crl 2339 90
DigiCert http://crl3.digicert.com/evca1-g1.crl 5393 100
GoDaddy http://crl.godaddy.com/gds3-37.crl 6848 153
Comodo http://crl.comodoca.com/COMODOExtendedValidationSecureServerCA.crl 12959 351
TrustCenter http://crl.ix.tcclass3.tcuniversal-i.trustcenter.de/crl/v2/tc_class3_L1_CA_IX.crl 16138 407
Entrust http://crl.entrust.net/level1e.crl 40995 1005
Symantec/VeriSign http://EVIntl-crl.verisign.com/EVIntl2006.crl 207922 5972
* CRL count was determined using “curl url>crl & openssl crl -in crl -inform der -text | grep -c “Serial”
* Size was determined using the Content-Length header, “curl –verbose –url *”

 

OCSP response Size
CA Host Size
Comodo ocsp.comodoca.com 471
Digicert ocsp.digicert.com 471
GlobalSign ocsp2.globalsign.com 1491
CyberTrust sureseries-ocsp.cybertrust.ne.jp 1588
StartSSL ocsp.startssl.com 1596
Symantec/Verisign ocsp.verisign.com 1739
GoDaddy ocsp.godaddy.com 1923
Entrust ocsp.entrust.net 1939
Certum ocsp.certum.pl 2113
Trustwave ocsp.trustwave.com 2519
TrustCenter ocsp.tcuniversal-I.trustcenter.de 3135
Symantec/Geotrust ocsp.geotrust.com 3346

* Size was determined using the Content-Length header, “curl –verbose –url *”

 

OCSP Response Performance
CA Host Average (ms)
GlobalSign ocsp2.globalsign.com

95
DigiCert ocsp.digicert.com

156
GoDaddy ocsp.godaddy.com

163
COMODO ocsp.comodoca.com

202
StartCom ocsp.startssl.com

280
Enstrust ocsp.entrust.net

293
Symantec/GeoTrust ocsp.geotrust.com

293
Symantec/VeriSign ocsp.verisign.com

295
TrustWave ocsp.trustwave.com

297
TrustCenter ocsp.tcuniversal-I.trustcenter.de

389
CyberTrust sureseries-ocsp.cybertrust.ne.jp

421
Certum ocsp.certum.pl

568
* Measuring with Monitis points in US-MID, US-EST-US-WST, Canada, Denmark, Netherlands, Germany, Spain, UK, Sweden, China, Austrailia, Signapore, Japan were used.

 

CRL Repository Performance
CA Host Average (ms)
GlobalSign crl.globalsign.com 101
DigiCert crl3.digicert.com 102
Entrust crl.entrust.net 120
Comodo crl.comodoca.com 178
GoDaddy crl.godaddy.com 186
StartCom crl.startssl.com 267
TrustWave crl.securetrust.com 272
Symantec/GeoTrust EVSSL-crl.geotrust.com 298
Symantec/Verisign EVIntl-crl.verisign.com 298
TrustCenter crl.ix.tcclass3.tcuniversal-i.trustcenter.de 371
Certum crl.certum.pl 426
CyberTrust sureseries-crl.cybertrust.ne.jp 454
* Measuring with Monitis points in US-MID, US-EST-US-WST, Canada, Denmark, Netherlands, Germany, Spain, UK, Sweden, China, Austrailia, Signapore, Japan were used.

 

Measuring OCSP Responder Performance with Powershell

1 Reply

The other day I did a post about testing if OCSP stapling was working, but what about telling how fast your OCSP responder is?

Well that is what this post is about, on Unix based systems with curl you would do something along these lines:

time curl –verbose –url http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUA

BBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK/Rx1KPgcYaoT9vrBkD1rFqMCEhEh

D0Xjo/V7lgq3ziGoWG69rA==

But there is no time on Windows so how can you do it there?

PowerShell.exe
Measure-Command {Start-Process -wait “curl” “-verbose “”http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUA

BBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK/Rx1KPgcYaoT9vrBkD1rFqMCEhEh

D0Xjo/V7lgq3ziGoWG69rA==”””}

 

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 53
Ticks : 531200
TotalDays : 6.14814814814815E-07
TotalHours : 1.47555555555556E-05
TotalMinutes : 0.000885333333333333
TotalSeconds : 0.05312
TotalMilliseconds : 53.12

 

Here you see that it took 53 milliseconds to run the command, its important to note that there different overhead buried each time measurement approach (time vs Measure-Command) that make it inappropriate to compare the results from two approaches. With that said its still a good way to measure performance over time when using a single measurement approach.

Also if you wanted to do the same measurement for POSTs the command would look like one of these :

Measure-Command {Start-Process -wait “openssl” “ocsp -noverify -no_nonce -respout ocspglobalsignca.resp -reqout ocspglobalsignca.req

-issuer globalsigng2.cer -cert globalsign.com.cer -url “”http://ocsp2.globalsign.com/gsextendvalg2″” -header “”HOST”” “”ocsp2.globalsign.com”””}

 

Measure-Command {Start-Process -wait “curl” “-verbose -data-binary  @ocspglobalsignca.req -H “”Content-Type:application/ocsp-request””

http://ocsp2.globalsign.com/gsextendvalg2″}

Pulse data publicly availible

Leave a reply

SSL Pulse is an initiative ran by Qualys to monitor the overall health of the SSL deployments on the Internet. It is based on the SSLLABS work Ivan Ristik has done; he has recently published the data used to derive these reports.

There are some interesting findings in buried in the raw data, for example:

  • Most of the certificates (85%?) are expired.
  • Most of the certificates are self-signed or from internal PKIs.
  • Those 5 “shorter than 1024bit” keys in the Pulse Dashboard are down to 3 (based on manual verification) are time valid certificates from public CAs, two expire this year the last in 2014.
Host Issuance Date Expiration Date Key Size Issuer
www.pysoft.com 01/25/2009 02/24/2014 512 Equifax Secure Global eBusiness CA-1
www.comlink.com.br 10/13/2009 11/07/2012 512 Thawte Premium Server CA
www.rtp.com 04/13/2009 06/04/2012 512 Thawte Premium Server CA

 

  • There are 2,472 RSAwithMD5 certificates in the 215,607 sample-set or around .01% of the hosts.

This last point gives us some context to some numbers Venafi published recently, they indicated 17.4% of the certificates they see are signed using MD5; this is a rate significantly higher than what we see here. Its probably safe to assume the difference is that their sample is primarily derived from intranets where private CAs are commonly are set up and forgotten.

For me the largest conclusion we can take from this data appears to be that there is a large number of organizations who set-up SSL (and PKIs) and simply forget about them – this is of course not a surprise but it’s neat to see it backed up with numbers.

Ryan

 

A look at the new Windows Update SSL certificates

17 Replies

This morning I noticed a tweet by Mikko about the Windows Update certificate chain looking odd so I decided to take a look myself.

I started with the webserver configuration using SSLLABS, unfortunately it did not fare well:

Looking a little closer we see a few things of interest:

  • SSLLABS is unable to validate the certificate
  • The server is using weak ciphers
  • The server is vulnerable to the BEAST attack
  • The server is not using an Extended Validation  (EV) Certificate
  • The server is supporting SSL 2.0

To understand the specifics here we needed to look a little deeper, the OpenSSL s_client is a great tool for this:

openssl s_client –showcerts -status –connect www.update.microsoft.com:443

Loading ‘screen’ into random state – done

CONNECTED(0000017C)

OCSP response: no response sent

depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 1

verify error:num=20:unable to get local issuer certificate

verify return:0

—

Certificate chain

0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com

i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

—

Server certificate

—–BEGIN CERTIFICATE—–

MIIF4TCCA8mgAwIBAgITMwAAAAPxs7enAjT5gQAAAAAAAzANBgkqhkiG9w0BAQUF

…

—–END CERTIFICATE—–

1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update S

ecure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

—–BEGIN CERTIFICATE—–

MIIGwDCCBKigAwIBAgITMwAAADTNCXaXRxx1YwAAAAAANDANBgkqhkiG9w0BAQUF

…

—–END CERTIFICATE—–

subject=/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update

Secure Server CA 1

—

No client certificate CA names sent

—

SSL handshake has read 3403 bytes and written 536 bytes

—

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : TLSv1

Cipher    : AES128-SHA

Session-ID: 33240000580DB2DE3D476EDAF84BEF7B357988A66A05249F71F4B7C90AB62986

 

Session-ID-ctx:

Master-Key: BD56664815654CA31DF75E7D6C35BD43D03186A2BDA4071CE188DF3AA296B1F9674BE721C90109179749AF2D7F1F6EE5

Key-Arg   : None

PSK identity: None

PSK identity hint: None

Start Time: 1339954151

Timeout   : 300 (sec)

Verify return code: 20 (unable to get local issuer certificate)

—

read:errno=10054

 

With this detail we can also look at the certificates with the Windows Certificate viewer, we just extract the server certificate Base64 and put it into a text file with a .cer extension and open it with Explorer:

   
   
   

 

From these we see a few additional things:

  • OCSP Stapling is not enabled on the server
  • The issuing CA was created on 5/30/2012 at 8:49pm
  • The issuing CA was issued by the 2001 SHA1 “Microsoft Root Authority”

So with this extra information let’s tackle each of these observations and see what conclusions we come to.

 

SSLLABS is unable to validate the certificate; there are two possible reasons:

a. The server isn’t including the intermediate certificates (it is) and SSLLABS doesn’t chase intermediates specified in the AIA:IssuerCert extension (doubt it does) or that extension isn’t present (it is).

b. The Root CA isn’t trusted by SSLLABS (which appears to be the case here).

My guess based on this is that Ivan only included the certificates in the “Third-Party Root Certification Authorities” store and did not include those in the “Trusted Root Certification Authorities” which are required for Windows to work.

Basically he never expected these Roots to be used to authenticate a public website.

[2:00 PM 6/18/2012] Ivan has confirmed he currently only checks the Mozilla trusted roots, therefor this root wouldn’t be trusted by SSLLABS.

Microsoft’s decision to use this roots means that any browser that doesn’t use the CryptoAPI certificate validation functions (Safari, Opera, Chrome on non-Windows platforms, Firefox, etc.) will fail to validate this certificate.

This was probably done to allow them to do pinning using the “Microsoft” policy in CertVerifyCertificateChainPolicy.

I believe this was not the right approach since I think it’s probably legitimate to use another browser to download patches.

[2:00 PM 6/18/2012] The assumption in this statement (and it may turn out I am wrong) is that it is possible for someone to reach a path where from a browser they can download patches; its my understanding this is an experience that XP machines using a different browser have when visiting this URL I — I have not verified this.

[3:00 PM 6/18/2012] Harry says that you have not been able to download from these URLs without IE ever, so this would be a non-issue if that is the case.

To address this Microsoft would need to either:

  • Have their PKI operate in accordance with the requirements that other CAs have to meet and be audited and be found to meet the requirements of each of the root programs that are out there.
  • Have two separate URLs and certificate chains one for the website anchored under a publicly trusted CA and another under this private “Product” root. The manifests would be downloaded from the “Product” root backed host and the web experience would be from the “Public” root backed host.
  • Cross certifying the issuing CA “Microsoft Update Secure Server CA 1” under a public CA also (cross certification), for example under their IT root that is publically trusted and include that intermediate in the web server configuration also. Then have a CertVerifyCertificateChainPolicy implementation that checks for that CA instead of the “Product” roots.

 

The server is using weak ciphers; the server is using several weak ciphers:


I see no reason to support the MD5 based ciphers as I find it hard to believe that there are any clients that can communicate with this site that do not support their SHA1 equivalents.

 

[2:00 PM 6/18/2012] I have been told I am too critical by calling these MD5 based ciphers as weak in that they are used as HMAC, it is true that when used with a key as is the case with HMAC the current attacks are not relevant. With that said any client that supports these suites will also support their SHA1 counterpart and there is no reason to support the weaker suites that use MD5.

 

The server is vulnerable to the BEAST attack; and SSLLABS isn’t able to tell if the server is specifying a cipher suite preference, this means it probably is not.

It is the cipher suite ordering issue that is actually resulting in the warning about the BEAST attack though. It is addressed by putting RC4 cipher suites at the top of the cipher suite order list.

[2:00 PM 6/18/2012] It’s been argued the BEAST attack isn’t relevant here because the client is normally not a browser, these pages that are returned do contain JS and there are cases where users visit it via the browser — otherwise there would not be HTML and JS in them. As such the attacker could use the attack to influence you to install malicious content as if it came from Microsoft. Maybe its not a leakage of personal information initially but its an issue.

 

It is not using an Extended Validation (EV) Certificate; this is an odd one, is an EV certificates necessary when someone is attesting to their own identity? Technically I would argue no, however no one can reasonably expect a user to go and look at a certificate chain and be knowledgeable enough to that this is what is going on.

The only mechanism to communicate the identity to the user in as clear a way is to make the certificate be an EV certificate.

Microsoft really should re-issue this certificate as an EV certificate – if there was ever a case to be sure who you are talking to it would certainly include when you are installing kernel mode drivers.

 

The server is supporting SSL 2.0; this also has to be an oversight in the servers configuration of SSL 2.0 has been known to have numerous security issues for some time.

They need to disable this weak version of SSL.

 

OCSP Stapling is not enabled on the server; OCSP stapling allows a webserver to send its own revocations status along with its certificate improving performance, reliability and privacy for revocation checking. According to Netcraft Windows Update is running on IIS 7 which supports it by default.

This means Microsoft is either not allowing these web servers to make outbound connections or they have explicitly disabled this feature (login.live.com has it enabled and working). While it is not a security issue per-se enabling it certainly is a best practice and since it’s on by default it seems they are intentionally not doing it for some reason.

 

The issuing CA was created on 5/30/2012 at 8:49pm; this isn’t a security issue but it’s interesting that the issuing CA was created four days before the Flame Security advisory. It was a late night for the folks operating the CA.

 

That’s it for now,

 

Ryan

Redirecting HTTP to HTTPS in IIS

Leave a reply

So you have been using SSL on your IIS 7.5 or greater server for some time now; to get here you had to do a few things:

  1. You scrubbed your site content to ensure all URLs are using their relative form, e.g. “src=’//images\image.png” or explicitly reference the use of HTTPS.
  2. You have tested for certificate and SSL related problems like mixed content, appropriately tagging cookies as secure.
  3. You have ensured that you follow the best practices guidance for SSL server configuration and verified you get an A on  SSLLabs.

Are you done? Not yet there are a few things left for you to do, the most obvious being redirecting all traffic to the SSL version of your site!

This is easy enough to accomplish but before you do so you should probably monitor your CPU usage during your peak so to ensure you have some headroom. This isn’t likely to be a problem as most web-servers are not CPU bound but it’s always good to check.

Once you know you are OK then it’s just a matter of deciding which approach to use, you have two choices:

  1. Dynamically rewriting via code in your ASPX pages
  2. Using the IIS URL Rewrite  module

If you are familiar with the IIS configuration you’re probably asking yourself what about the “Require secure channel (SSL)” option in the IIS MMC? Unfortunately this doesn’t do redirecting it only requires the use of SSL on a given site/folder/file.

So how do you decide which approach to use? The answer to that question is dependent on both your environment and personal preference.

For example if 100% of your site is ASPX based (no static HTML), you have your code structured so that there is a common include and you are not already using the URL Rewrite module I would use method one based on KB239875.

I suspect that these conditions will not be met for most people so let’s focus on method two, using the URL Rewrite  module.

This approach has a number of benefits, for one having this module allows you to leverage remapping for other purposes also for example maintaining old links that have SEO value. From a security standpoint it’s also a good approach as it keeps this decision one of policy that is enforced in a central place.

To use the URL rewrite approach you will need to do the following:

 

1. Install the URL Rewrite module (x86, x64).

2. Add a rule to rewrite all HTTP URLs to HTTPS.

a. Open your “web.config” with your favorite editor.

b. Find the “configuration\system.webserver\rewrite\rules” section.

c. Add the following text block:

<rule name=”Redirect to HTTPS” stopProcessing=”true”>

<match url=”(.*)” />

<conditions>

<add input=”{HTTPS}” pattern=”^OFF$” />

</conditions>

<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />

</rule>

3. Restart IIS.

Now just go to your website over HTTP and you will see you are redirected to the HTTPS instance of the site.

 

Ryan

Additional Resources

IIS Rewrite Module Configuration Reference

10 URL Rewriting Tips and Tricks

Automatically redirect HTTP requests to HTTPS on IIS7 using URL Rewrite 2.0