Setting up HTTP Compression For Your SharePoint Portal
- A 2 GHz or faster processor
- 2 GB of RAM
- 3 times the harddrive space as the estimated protected data
- Paging Files
- The Recycle Bin
- Volume Information Folder
For organizations that have certain security standards, it is customary that the common name on certificates must match the host name of the machine. Furthermore, wildcard certificates are generally unacceptable because of the broad reach that such a certificate implementation could have.
The solution that most organizations will take in light of these considerations is to use a subject alternative name (SAN) attribute on their certificate in order to avoid the ugly certificate mismatch screen that appears in IE7. In IE6 it was an issue because of the homely NT login box that appeared, however this user experience is amplified in IE7 since the certificate mismatch error will consume an entire page and is therefore not the most attractive experience for users. What a SAN attribute basically accomplishes is the allowance of multiple identities to be bound as the subject on a certificate, whether it is something like a URL, IP, etc. for the certificate request attribute, so that the mismatch never occurs.
So far, this sounds like a pretty good solution for people whose CN must match the hostname of the SharePoint machine. But, if you dig a little deeper into the request architecture for a default Windows Server 2003 instance you will see that natively it is not possible to submit a certificate request where subject alternative names are identified. This of course is a large problem.
The solution is pretty straight forward though, and involves a combination of creating a new certificate request .inf along with a combination of command lines that are run both on the requesting machine and the issuing CA box.
Step 1 – Create a New Certificate Request .inf file
The first step is to create a sharepointcertreq.inf file that will act as an parameter for certificate creation input. This can just be done in your favorite text editor, notepad suffices just fine. Within the .inf file, place the following content:
Subject = “CN=sharepointhostname”
KeySpec = 1
KeyLength = 1024
Exportable = FALSE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
OID = 184.108.40.206.220.127.116.11.1
Step 2 – Create The New Certificate Request
Using this .inf file, you can pass it in as a parameter to create a certificate request using the certreq tool. This is done on your SharePoint machine that you desire the certificate for. If you are having trouble finding the certreq tool, you might not have it installed on the server. The certreq tools is a part of the Windows Server 2003 Administration Tools Pack, which you can download from here:
which will include certreq.exe. Once you have located the executable, submit the following parameters with it:
certreq -new c:\sharepointcertreq.inf c:\sharepointservercert.req
As a side note, this may take a few moments to execute, mainly depending on the size of the key that is specified in the sharepointcertreq.inf file.
Step 3 – Change Some Registry Attributes
Step 3 occurs on the issuing CA machine, so switch to that machine.
Using the certutil -setreg method is nice because you can directly avoid using regedit and navigating through its innards to the appropriate attributes and flags. Issue the following command to support subject alternative names:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Step 4 – Restart Certificate Services
Once you have gotten this far with the changes, it is time to restart certificate services so that the changes take effect. This is best done by creating a small reusable .bat file, since you might be doing certificate configuration a fair amount if you are heavily tailoring the MCS implementation. Like the previous step, this happens on the issuing CA.
Create the following in a CertficateRestart.bat file:
REM – File: CertficateRestart.bat
REM – Description: Restart’s Certificate Services
REM – Author: Adam Buenz
echo Restarting Certificate Services…
net stop “certificate services”
net start “certificate services”
echo Certificate Services Has Been Successfully Restarted
Run the .bat file in order to restart certificate services, which should display “Certificate Services Has Been Successfully Restarted” when it is complete.
Step 5 – Submit the certificate request
With the request file that you created previously, you now have to issue the certificate request. Place the sharepointservercert.req file that you previously created on some sort of accessible medium from the issuing CA machine, best stored on the actual disk somewhere. Following, run the below command in order to submit the certificate request with the relevant SAN attributes:
certreq -q -attrib “SAN:DNS=mysharepointserverSAN” -submit sharepointservercert.req
Once this is complete, your certificate request will go through with the relevant SAN attributes.