Asked by:
https-inspect with Staat der Nederlanden Root CA - G2

Question
-
My TMG 2010 sp2u1 is using http-inspect with a generated certificate from my Enterprise Root CA. Which works great with all sites except sites from the Dutch Government which are signed with the Staat der Nederlanden Root CA - G2 (which is in trusted Root CA of Windows 2008 R2 by default)
Validation only works, but with inspect it just says in the log:
Failed Connection Attempt
Log type: Web Proxy (Forward)
Status: 0x8009000a
Rule: Authenticated Internet DMZ&LAN > WAN
Source: Internal (My Internal IP:59493)
Destination: External (www.logius.nl 80.95.165.206:443)
Request: 80.95.165.206:443
Filter information: Req ID: 1366d24f; Compression: client=No, server=No, compress rate=0% decompress rate=0%
Protocol: https-inspect
User: MYDOMAIN\MyUsername
Object source: Internet (Source is the Internet. Object was added to the cache.)
Cache info: 0x0
Processing time: 0 MIME type:
adding sites that use Staat der Nederlanden Root CA - G2 to the HTTPS inspection exception list works... But there are loads of dutch government sites :)
Can anybody test one of these sites with https-inspection enabled:
https://as.digid.nl
https://www.logius.nl
https://www.officielebekendmakingen.nl/
https://www.overheid.nl/Any idea what can be wrong?
Wednesday, February 29, 2012 4:38 PM
All replies
-
Hi,
Thank you for the post.
When you browser the https site(www.logius.nl), what is error message you receive in the page?
Regards,
Nick Gu - MSFT
- Edited by Nick Gu - MSFTModerator Thursday, March 1, 2012 5:51 AM
Thursday, March 1, 2012 5:51 AMModerator -
Just the default Internet Explorer error (translated from dutch): The page could not be displayed.
It is certainly not a TMG error page...
This is for all clients and only with sites that is signed by this CA
- Edited by Nico 83 Thursday, March 1, 2012 9:02 AM
Thursday, March 1, 2012 9:00 AM -
I did some comparing and Staat der Nederlanden CA seems to use a SHA256 hash instead of SHA-1 which is common for Certificate Authorities.
Furthermore, new first time visited sites (with the Staat der Nederlanden CA signed certificates) are greeted on the TMG by an Alert Error: CA Certificate Failed To Sign
Forefront TMG failed to sign a cloned SSL server certificate for a destination server using a certification authority (CA) certificate.
It was hard to pinpoint these, since I needed to filter the log for the specific time that Alert was created, and filter the failed https-inspect protocol...Could the SHA256 CA signing be the problem? And if so, how to solve this?
http://technet.microsoft.com/en-us/library/ee796230.aspx says to remediate the alert I need to use the exclusion list... Which is really not a option for all the dutch government sites...
- Edited by Nico 83 Friday, March 2, 2012 10:34 AM
Friday, March 2, 2012 8:14 AM -
hello,
I have just checked your scenario and also received weird errors. So I tried to download the web sites certificate (just the leaf one with the subject of www.officielebekendmakingen.nl). I saved the certificate to a WEBCERT.CER file and tried verifying it with CERTUTIL -urlfetch -verify WEBCERT.CER command. The output says that the CERTUTIL cannot find its issuer's certificate, altough the IE browser was able to display the whole certificate chain.
The chain looks like this:
www.officielebekendmakingen.nl
Getronics CSP Organisatie CA - G2
Staat der Nederlanden Organisatie CA - G2
Staat der Nederlanden Root CA - G2If you open the www.officielebekendmakingen.nl certificate in the browser, you can look at the Authority Information Access (AIA) extension. Although the extension contains OCSP path for revocation checking, it does not contain a reference to the .CRT of the IssuingCA, so the certificate client is not able to find the IssuingCA's certificate to build the chain.
I do not understand why the IE was able to build the whole chain while regular certificate client is not able to do it the same, but this seems to be the problem. The certificate client is not able to build the chain, because the intermediate certificates, the "Getronics CSP Organisatie CA - G2", and "Staat der Nederlanden Organisatie CA - G2" are not installed in the Intermediate Certification Authorities store of the TMG computer.
I am going to install them and will report back.
ondrej.
Friday, March 2, 2012 1:38 PM -
hello, so after installing the intermediate certificates the bahviour didn't change.
TMG drops the connection itself after receiving some TLS answer from the server. The server's answer (encrypted though) looks the same as the answer that would be received by a normal IE client without the SSL inspection in between. Looks like TMG does not like the TLS behavior of the NL servers.
I have also checked their SSL with https://www.ssllabs.com/ssldb/analyze.html?d=www.officielebekendmakingen.nl and everything looks veery similar to what (for example) mail.google.com shows - which actually works over SSL inspection.
So that looks like another TMG SSL inspection bug to me.
ondrej.
Saturday, March 3, 2012 9:50 AM -
so here I am again:
- installing the intermediate CAs didn't solve the problem. The TMG-SSLServer side exchange is just the same as it is between the Client-SSLServer if the TMG SSL Inspection is not enabled. The SSLServer also does not require client certificates, so not even this could be a possible reason. This looks like another TMG bug in SSL Inspection
- with the TMG SSL Inspection enabled, the TMG logs "Forefront TMG failed to sign a cloned SSL server certificate for a destination server using a certification authority (CA) certificate" which looks like the real reason - something in the SSLServer's certificate prevents TMG from faking its certificate. It may be the SHA2 signature of the original - although there is no phylosophical reason, having TMG CA SHA1 while signing the ServerFakeWithSHA2, but this may be the problem.
- I have also tried to disable the SSL inspection while enabling just the "Do not inspect traffic, but validate site certificates" option. Whith this option enabled, it works. This indicates again that the "cloning process" is the reason.
Overall it looks like TMG either cannot clone SHA2 certificates or rather some other content of the NL certificates prevent TMG from cloning.
ondrej.
Saturday, March 3, 2012 10:19 AM -
Right. Just as I suspected... So this seems to be a sha signing bug, how do I procede? I will start making exceptions, but does the TMG team look in these topics, or do I really need to call MS support? (for this to be fixed in future updates/service packs)
- Edited by Nico 83 Monday, March 5, 2012 12:07 PM
Monday, March 5, 2012 10:02 AM -
Log a support call for it with Microsoft.
- Proposed as answer by rt3465345 Thursday, March 29, 2012 12:15 AM
Tuesday, March 27, 2012 8:08 PM -
Logged one last week, they're working on it now.Wednesday, March 28, 2012 10:26 AM
-
hi, do you have any update on the issue? thanks!
Tuesday, June 26, 2012 3:26 PM -
Any resolution to this problem?
Richard Artes.
Thursday, July 4, 2013 12:45 PM -
See below the closing summary of the case we had about this issue.
The scripts works fine, tested it with a issued certificate from our own CA also works.
The problem is related to how we generate the certificate for HTTPS inspection. It must be issued using CNG API. (Certificate New Generation v3)
PROBLEM
Web access from internal computers to remote HTTPS sites using HTTPS inspection feature fails with error 0x8009000a
RESOLUTION
Use the following script to generate a custom CNG certificate for HTTPS inspection:
- Copy the following lines in a file with .ps1 extension:
#SCRIPT - Generate Self-signed CNG Certificates for Certificate signing purpose, This will be used by TMG Https Inpection
#AUTHOR - Microsoft Corporation
#VERSION - 1.0
#$ErrorActionPreference = "Stop"
Write-Host "`n WARNING: This script sample is provided AS-IS with no warranties and confers no rights." -ForegroundColor red
Write-Host "`n This script sample will generate self-signed CNG Authority certificate to be used by TMG HTTPS Inspection feature"
Write-Host " in the Local Computer Personal certificate store.`n Private is can be exported. As well the .cer and .pfx files will be save ini the provided directory`n`n"
$outputDir = Read-Host "`nEnter directory path where certificate will be saved"
$Subject = Read-Host "`nEnter the Subject for certificate "
$password = Read-Host -assecurestring "`nPfx password"
$ValidateDays = Read-Host "`nCertificate Validity days: (please enter number of days)"
#Generate cert in local computer My store
$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"
$name.Encode("CN=$Subject", 0)
# The Key
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"
$key.ProviderName = "Microsoft Software Key Storage Provider" # CNG is Software Key Storage "Microsoft RSA SChannel Cryptographic Provider"
$key.KeySpec = 0 # was 1 but 0 looks needed for CNG http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx
$key.keyUsage =0xfffff # Set the key usage to all usage http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx
$key.Length = 2048
$key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" # Allow Write NT AUTHORITY\SYSTEM Allow Write BUILTIN\Administrators Allow Write NT AUTHORITY\NETWORK SERVICE
$key.MachineContext = 1
$key.ExportPolicy = 1 # Allow private key to be exported XCN_NCRYPT_ALLOW_EXPORT_FLAG 0x00000001 http://msdn.microsoft.com/en-us/library/windows/desktop/aa379002(v=vs.85).aspx
$key.Create()
Write-Host "`nPrivate Key created ......"
#The certificate itself
$cert = new-object -com "X509Enrollment.CX509CertificateRequestCertificate.1" # Interface for self signed cert request http://msdn.microsoft.com/en-us/library/windows/desktop/aa377124(v=vs.85).aspx
$cert.InitializeFromPrivateKey(2, $key, "")
$cert.Subject = $name
$cert.Issuer = $cert.Subject
$today =get-date
$cert.NotBefore = $today.AddDays(-1) # yesterday
$cert.NotAfter = $cert.NotBefore.AddDays($ValidateDays)
# Add Key usage to the certificate, this is needed as TMG chek this during certificate import
$KeyUsage = new-object -com "X509Enrollment.CX509ExtensionKeyUsage.1"
$Keyusage.InitializeEncode(0x4) #0x4 XCN_CERT_KEY_CERT_SIGN_KEY_USAGE http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx
$cert.X509Extensions.Add($keyusage)
$cert.Encode()
Write-Host "`nCertificate created ......"
$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"
$enrollment.InitializeFromRequest($cert)
$certdata = $enrollment.CreateRequest(0)
$enrollment.InstallResponse(2, $certdata, 0, "")
Write-Host "`nCNG self signed installed in the Computer certificate local store"
#Create the ".pfx" and ".cer" version by exporting the just inserted certificate
$store = new-object System.Security.Cryptography.X509Certificates.X509Store "My","LocalMachine"
$store.Open("ReadOnly")
$certs = $store.Certificates
$cerPath = $outputDir+ "\"+ $Subject+ ".cer"
$pfxPath = $outputDir + "\" + $Subject + ".pfx"
foreach ($cert in $certs)
{
# write-host $cert.Subject
if($cert.Subject -like ("CN="+ $Subject))
{
$ExportCert = $cert.Export(1) #http://msdn.microsoft.com/fr-fr/library/system.security.cryptography.x509certificates.x509certificate2.aspx 1=.cer 3=.fx
[System.IO.File]::WriteAllBytes(($cerPath), $ExportCert)
Write-Host "`nCertificate .cer exported to: " $cerPath
$PFXStrData =$cert.Export(3,$password)
[System.IO.File]::WriteAllBytes($pfxPath, $PFXStrData)
Write-Host "`nCertificate with private Key .pfx exported to: " $pfxPath
}
}
$store.close()
#now Import it to Local computer Root store
$RootCert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 $cerPath
$RootStore = new-object System.Security.Cryptography.X509Certificates.X509Store "Root","LocalMachine"
$RootStore.Open("ReadWrite")
$RootStore.Add($RootCert)
Write-Host "`nCertificate installed in Local computer - Trusted root"
$RootStore.close()
Write-Host "`nDone ... `n" -ForegroundColor Green
- Open a Power Shell window and run the script. Follow the instructions.
- The .cer and .pfx will be save in the folder of your choice. As well .cer will be installed in the local computer / trusted root.
- Configure the HTTPS inspection to use this custom certificate. Follow the steps described in:
http://technet.microsoft.com/en-us/library/dd441053
Generating the HTTPS inspection certificate
- Deploy the HTTPS inspection certificate in the client computers, just as you did for your current one. You could deploy it using both AD DS and manually. For detailed description follow steps in:
http://technet.microsoft.com/en-us/library/dd441069
Deploying the HTTPS inspection trusted root CA certificate to client computers
Regards, Bas
- Proposed as answer by BSterkenburg Friday, July 5, 2013 2:51 PM
Friday, July 5, 2013 5:37 AM -
I have the same problem, but we a subordinate CA certificate for HTTPS inspection signed by our inhouse CA.
How can I get the TMG to work with this certificates and SHA256 encrypted websites?
Friday, May 23, 2014 8:09 AM -
Hi Felix95,<o:p></o:p>
You could just create a V3 certificate from your own CA. Although it is stated that it is not supported, the engineer that help us with the case told me they were going to update their documentation. They never did but I've tested it and its works without any problems.<o:p></o:p>
Regards, Bas
Saturday, May 24, 2014 10:25 AM -
I created a V3 certificate with Server 2008 Enterprise Sub-CA template and imported it into my TMG. Now I can't access any HTTPS websites. The TMG log shows an allowed https-inspect connection, but on the client side Firefox shows sec_error_bad_signature and IE doesn't provide any error information.Saturday, May 24, 2014 6:38 PM
-
I used this walkthrough at the time (but then with a V3 certificate). Please check your certificate settings.
http://blog.msedge.org.uk/2010/01/generating-tmg-https-inspection.html
Regards, Bas
- Edited by BSterkenburg Sunday, May 25, 2014 8:40 AM
- Proposed as answer by Felix95 Sunday, May 25, 2014 10:59 AM
Sunday, May 25, 2014 8:39 AM -
Following this blog post it worked. It turned out, that you can only set CN entry. If you set more subject names like O or OU it won't work.
Thank you for your help!
Sunday, May 25, 2014 10:59 AM