[Source: http://geekswithblogs.net/EltonStoneman]
If you have a solution with secure HTTPS endpoints but no suitable certificate for development and test environments, you can self-certify using a combination of IIS 6 Resource Kit tools, and manual steps. Chris Adams gives a good overview in this post, but there are a couple of additional things to consider in a distributed environment, which I’ll cover in this walkthrough.
The walkthrough is based on the following infrastructure:
– where XYZ-FRONTEND and XYZ-BACKEND are independent load-balanced Web farms, which each have SSL endpoints. XYZ-FRONTEND exposes an HTTPS website, and connects to XYZ-BACKEND via HTTPS Web services.
1. Get the IIS 6 Resource Kit Tools
Download it from here – it’s not limited to IIS6 so you can also use the tools in IIS5.
2. Self-certify the back-end farm
On XYZ-BACKEND-A install the resource kit and run SelfSSL.exe (by default in C:\Program Files\IIS Resources\SelfSSL) to create and apply an SSL certificate:
- selfssl /n:cn=xyz-backend /t /v:365
This creates, trusts and applies a certificate to the default website on the A node, which is valid for a year. Note that the DNS name of the farm is used, so requests to https://xyz-backend/url.svc will succeed, but requests to https://xyz-backend-a/utl.svc will fail, as the certificate does not apply to the resolved host names.
Export and deploy the new certificate to XYZ-BACKEND-B using IISCertDeploy.vbs (by default in C:\Program Files\IIS Resources\IISCertDeploy):
- iiscertdeploy.vbs -e c:\xyz-backend.pfx -p xyz-backend
- iiscertdeploy.vbs -c c:\ xyz-backend.pfx -p xyz-backend -s XYZ-BACKEND-B
This applies the certificate to the default website on the B node, but does not trust it. To trust the certificate:
- Run MMC
- Add the “Certificates” snap-in, for “Computer Account”, “Another Computer”, XYZ-BACKEND-B
- Copy the xyz-backend certificate from Personal\Certificates to Trusted Root Certification Authorities\Certificates
3. Self-certify the front-end farm
Similarly for the frontend, login to XYZ-FRONTEND-A:
- selfssl /n:cn=xyz-frontend /t /v:365
- iiscertdeploy.vbs -e c:\xyz-frontend.pfx -p xyz-frontend
- iiscertdeploy.vbs -c c:\ xyz-frontend.pfx -p xyz-frontend -s XYZ-FRONTEND-B
- Run MMC
- Add the “Certificates” snap-in, for “Computer Account”, “Another Computer”, XYZ-FRONTEND-B
- Copy the xyz-frontend certificate from Personal\Certificates to Trusted Root Certification Authorities\Certificates
4. Configure the front-end to trust the back-end
The farms now have trust relationships within themselves, but the front-end does not trust the back-end, as the certificate is self-published. To trust the back-end, copy the exported xyz-backend.pfx file to XYZ-FRONTEND-A and import the certificate to the trusted store:
- Run MMC
- Add the “Certificates” snap-in, for “Computer Account”, “Local Computer”
- From Trusted Root Certification Authorities\Certificates, right-click, “Import” and navigate to xyz-backend.pfx
- Enter the password from step 2 (xyz-backend in this example)
- Add the “Certificates” snap-in, for “Computer Account”, “Another Computer”, XYZ-FRONTEND-B
- From Trusted Root Certification Authorities\Certificates, right-click, “Import” and navigate to xyz-backend.pfx
- Enter the password from step 2
5. Set up the sites to require SSL
In IIS manager, configure whole sites or individual pages to require SSL from the Directory Security tab, and specify whether client certificates are required.
This establishes a trust relationship within and between the farms. Web browsers will display a certificate warning when they connect to an https://xyz-frontend URL, which the user can ignore, but other types of client may fail the connection. If clients can’t connect, you’ll need to trust the certificate by importing xyz-frontend.pfx to the trusted store on the client machines, as in step 4.
Note that if one of the farms consists of BizTalk servers, the procedure is exactly the same. Ensure that the SSL configuration in your receive location matches the configuration in IIS, otherwise the service won’t activate – but it will give you a useful warning (“The SSL settings for the service ‘SslRequireCert’ does not match those of the IIS ‘Ssl'”) if there is a mismatch.