Subject Alternative Name necessary?
Hi, all. Unsure if this is the right forum! Regarding PKI and certs for internal servers, if you issue an ssl cert for a website (where the request is generated from IIS 7's request wizard), it appears to me that if you visit https://hostname you will not get a certificate error about the hostname not matching. However, if someone links to that internal website using https://hostname.domain.com (the fqdn), the certificate's hostname does not match the URL entered and the user gets a bad cert warning. Because we can't very effectively control how links are formatted (short or fqdn, even to insternal sites), to ensure people don't get the error for an fqdn, it seems to me that the only solution is to enable subject alternative names using the command certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 However, for an AD integrated Enterprise issuing CA, this could be a huge problem! The best practices guide (http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx#BKMK_Security) says Whenever possible, specify a SAN by using certificate extensions instead of request attributes to avoid enabling EDITF_ATTRIBUTESUBJECTALTNAME2. But I don't know what this means! Is this a workaround to what would otherwise mean allowing SANs in every cert request (such as user or machine requests, which would be auto-approved)? If not, is the best alternative truly to build a standalone CA for www and other SAN-necessary certs? Finally, am I missing something major? Is there something about how I'm doing the certificate requests, or something about our environment, that would cause a cert issued from an IIS wizard to work if you visit the short hostname, but not the FQDN of the website? Thanks!!
February 23rd, 2011 2:47pm

The best practices guide (http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx#BKMK_Security) says Whenever possible, specify a SAN by using certificate extensions instead of request attributes to avoid enabling EDITF_ATTRIBUTESUBJECTALTNAME2. But I don't know what this means! Is this a workaround to what would otherwise mean allowing SANs in every cert request (such as user or machine requests, which would be auto-approved)? It means it is recommended to configure SAN in the Extensions section instead of the RequestAttributes section. You can refer to the sample file for the difference between the sections http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx#BKMK_Certreq For SSL to work properly, the computer name we type in the URL must appear in one of the following locations of the certificate: Subject field. SAN field. It means that the certificate error will not occur if both the hostname and FQDN name appear in one of the locations mentioned above. Hope the information is helpful.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
February 24th, 2011 2:54am

For SSL to work properly, the computer name we type in the URL must appear in one of the following locations of the certificate: Subject field. SAN field. It means that the certificate error will not occur if both the hostname and FQDN name appear in one of the locations mentioned above. Hi just a minor correction here, if you use SAN field, the hostname / FQDN must appear here. So for example if the certificate contains CN=www.contoso.com and SAN:DNS=webmail.contoso.com then the certificate will not match for www.contoso.com because it is not included in the SAN. For more information see for example http://www.digicert.com/subject-alternative-name-compatibility.htm or http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/08ffe96e-eb76-49b6-813a-3db45994965a Kind regards Martin Rublik
February 24th, 2011 9:13am

Thanks for that. I've seen that URL before and wasn't sure it was what I was looking for. As it turns out, it was. This is a way to allow subject alternative names for requests without enabling that flag they tell you not to enable on an enterprise CA. It seems kind of strange that without enabling that flag, you can still make requests with SAN's in it to the enterprise CA. Specifically, we're talking about adding short hostnames and long fqdn's to a webserver cert, both in the SAN field. So, in order to make this work repeatedly and accurately for IT administrators at my org, I've written a powershell script that will automate the process of making the request using the inf file, accepting the result, and exporting the .pfx version of the certificate for use on any target system. The request needs to be made from a Vista+ machine (as I've not used the ASN.1 encoding stuff and made certain other assumptions IIRC), and it can be the requestor's workstation or server machine. It assumes the request will be automatically processed, so the requestor must be in a group that is allowed to enroll for an ssl certificate and the template needs to not have 'CA certificate manager approval' checked under Issuance Requirements and the subject name must be supplied in the request, not built from AD. If you want to have a CA manager approve the request, the script could be very easily broken down to two scripts - the request script, and the part that is done when you get your .cer file back. The first part of the script is a template file for requestpolicy.inf, I call this requestpolicytemplate.inf, and so does the powershell script which replaces certain text strings and creates the requestpolicy inf for the host you want: ---- begin requestpolicytemplate.inf ---- [Version] Signature="$Windows NT$" [NewRequest] Subject="C=US,S=state,L=city,O=site,OU=IT,CN=hostname.domain" Exportable = TRUE ; TRUE = Private key is exportable (must be to request from client machine) KeyLength = 2048 ; Valid key sizes: 1024, 2048, 4096, 8192, 16384 KeySpec = 1 ; Key Exchange – Required for encryption KeyUsage = 0xA0 ; Digital Signature, Key Encipherment MachineKeySet = True ProviderName = "Microsoft RSA SChannel Cryptographic Provider" RequestType = PKCS10 ; or CMC. [Extensions] ; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7 ; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension. 2.5.29.17 = "{text}" _continue_ = "dns=hostname&dns=hostname.domain" [RequestAttributes] CertificateTemplate = InProduction-WebServer ; Modify for your environment by using the LDAP common name of the template. ;Required only for enterprise CAs. ---- end requestpolicytemplate.inf ---- The powershell script uses this file to make text replacements, create a new file, and put that in the certificate request. If you have UAC on, it must be run in an administrative command shell, or administratively elevated powershell. And, again, the user that makes the request has to be in an NT group that's allowed to enroll for the certificate. Finally, the name of the ssl server's template is hard coded into this file, and you must edit it to reflect your issuing certificate authority server name and name of CA itself. ---- begin generate_ssl_request.ps1 ---- function print_help { @" Usage: This command will take the hostname and DNS name of a web server and make a certificate request with the appropriate SAN fields filled out so that the certificate is valid whether the browser makes the request to https://hostname or https://hostname.domain.com Go like this: "@ Write-Host -Fore Yellow ".\generate_ssl_request.ps1 hostname domainname ""2 letter state code"" ""City Name"" ""Company Office Name""" @" All arguments must be present "@ } # End Function print_help # Main Block # First, make sure we passed anything at all in. # If not, show usage and exit. $hostname = $args[0] $domain = $args[1] $state = $args[2] $city = $args[3] $site = $args[4] $numArgs = $args.Length if ($numArgs -ne 5) { print_help; exit; } $fqdn=$hostname+"."+$domain # the PFX export needs a passphrase Write-Host "The certificate will need a pass phrase when it's exported and again when it's imported." Write-Host "Store this phrase securely before you continue and enter it in." $PassCrypto = Read-Host -assecurestring "Please enter a pass phrase for the certificate" $PassVerifyCrypto = Read-Host -assecurestring "Please re-enter the pass phrase" $Pass = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($PassCrypto)) $PassVerify = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($PassVerifyCrypto)) if ($Pass -cne $PassVerify) { Write-Host "Passwords don't match, exiting" exit } #clear PassVerify $PassVerify = "blah" Write-Host "I will be creating a request with these properties:" Write-Host "Short Hostname: $hostname" Write-Host "Fully Qualified Domain Name: $hostname.$domain" Write-Host "Two Letter State Abbreviation: $state" Write-Host "City: $city" Write-Host "Company Office Name: $site" Write-Host "" Write-Host "If this is OK, hit Enter" Write-Host "If this is not OK, hit CTRL-C or enter ""N"": " $quit = [Console]::ReadLine() $quit = $quit.ToLower() switch ($quit){ "n" {"You entered N, quitting"; exit} default {"Generating files and making request"; break} } # first generate the requestpolicy.inf from the template # Get-Item .\requestpolicytemplate.inf | % { (Get-Content $_) -replace "hostname",$hostname -replace "domain",$domain -replace "state",$state -replace "city",$city -replace "site",$site | sc -path .\$hostname.inf } ########################## #then create the request file with Certreq.exe -new <RequestPolicy.inf><CertificateRequest.req> Write-Host "Creating Request inf file and $hostname.req file" certreq.exe -f -new .\$hostname.inf .\$hostname.req #then sign the request certreq -submit -config "<ServerName\CAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>" Write-Host "Submitting Request to CA" certreq -f -submit -config "<CA SERVER NAME>\<COMMON NAME OF CA - what you see at top of certsrv.msc>" .\$hostname.req .\$hostname.cer #now we accept the response so we can export as password protected pfx Write-Host "Accepting Certificate" certreq -accept .\$hostname.cer #now we export as a password protected pfx Write-Host "Exporting accepted certificate with passphrase" certutil -f -privatekey -p "$Pass" -exportpfx $fqdn .\$fqdn.pfx #finally we remove this certificate from the user's store certutil -delstore MY $fqdn #a bit of cleanup Remove-Item .\$hostname.req Remove-Item .\$hostname.cer Remove-Item .\$hostname.inf #clear password $Pass = "blah" Write-Host "At this point, take your .pfx file and your password and import it" Write-Host "by double clicking and putting it into your personal cert store." Write-Host "Only after you do this, can you import the .pfx file with the IIS MMC" Write-Host "Once imported, delete your pfx file or save it and treat it like gold." Write-Host "Have fun!" ---- end generate_ssl_request.ps1 ---- So the process is put these two files in a directory, edit them to match your environment (name of CA and webserver template in the powershell script), and run elevated powershell on a windows Vista or later machine. You will wind up with a pfx file which you should be able to import / use elsewhere with the passphrase you supplied to the script. If anyone can think of a reason why this is a bad idea to do this way, I'd like to hear about it! Thanks!
Free Windows Admin Tool Kit Click here and download it now
February 28th, 2011 4:10pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics