A few days ago while starting TortoiseSVN it prompted me to update to version 1.7
After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.
SSL error: sslv3 alert certificate unknown
Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.
Root CA
|
v
Intermediate Certificate
|
v
Repository certificate
Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.
After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.
To “Untrust” the DigiNotar certificates on Windows 2003/XP without installing the MS patch,
you can add the Certificate “Blobs” to the following Certificate Store in the registry “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates”
<Name>Blob</Name><Type>REG_BINARY</Type>
You can find the “Blob” values on a patched system (see attached link).
These are all the current Certificates in Internet Explorer (including known fraudulent and new DigiNotar):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates
\1916A2AF346D399F50313C393200F14140456616
\2B84BFBB34EE2EF949FE1CBE30AA026416EB2216
\305F8BD17AA2CBC483A4C41B19A39A0C75DA39D6
\367D4B3B4FCBBC0B767B2EC0CDB2A36EAB71A4EB
\40AA38731BD189F9CDB5B9DC35E2136F38777AF4
\43D9BCB568E039D073A74A71D8511F7476089CC3
\471C949A8143DB5AD5CDF1C972864A2504FA23C9
\5DE83EE82AC5090AEA9D6AC4E7A6E213F946E179
\61793FCBFA4F9008309BBA5FF12D2CB29CD4151A
\637162CC59A3A1E25956FA5FA8F60D2E1C52EAC6
\63FEAE960BAA91E343CE2BD8B71798C76BDB77D0
\6431723036FD26DEA502792FA595922493030F97
\7D7F4414CCEF168ADF6BF40753B5BECD78375931
\80962AE4D6C5B442894E95A13E4A699E07D694CF
\86E817C81A5CA672FE000F36F878C19518D6F844
\9845A431D51959CAF225322B4A4FE9F223CE6D15
\B533345D06F64516403C00DA03187D3BFEF59156
\B86E791620F759F17B8D25E38CA8BE32E7D5EAC2
\C060ED44CBD881BD0EF86C0BA287DDCF8167478C
\CEA586B2CE593EC7D939898337C57814708AB2BE
\D018B62DC518907247DF50925BB09ACF4A5CB3AD
\F8A54E03AADC5692B850496A4C4630FFEAA29D83
After that you can remove DigiNotar from the Trusted Root Certification Authorities store:
certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
On Windows 2008 and newer you have a nifty option in Group Policy:
\Computer Configuration\Policies\Windows Settings\Public Key Policies\Untrusted Certificates
Install the patch on a (local) machine and export the certificates from your “Untrusted Publishers” store as DER encoded, you can import the DER files in the GPO.
Here is the registry hive export from a patched machine, including all certificates and blobs.
cheers,
Matthijs
A simple batchfile to remove 40 days old directories and logfiles from MS patches and updates, using forfiles.
@echo off
rem purge 40 days old MS update/patch files
forfiles /p “%windir%\SoftwareDistribution\Download” /d -40 /s /c “cmd /c if @isdir==TRUE rmdir /s /q @path”
forfiles /p “%windir%\SoftwareDistribution\Download” /d -40 /c “cmd /c if @isdir==FALSE del /Q @path”
forfiles /p “%windir%” /m “$NtUninstallKB*” /d -40 /s /c “cmd /c if @isdir==TRUE rmdir /s /q @path”
forfiles /p “%windir%” /m “KB*.log” /d -40 /c “cmd /c if @isdir==FALSE del /Q @path”
EXIT /B 0
If you use a SAN/NAS based umbraco webroot, access to the umbraco.config can get troublesome when using multiple webservers and in umbracoSettings.config
With Umbraco 4.5.2 using “umbracoContentXMLUseLocalTemp” can be the solution for this when you set its key value to “true”, but that is not the complete story!
When doing so Umbraco will create an umbraco.config FOLDER in the ASP.NET root. Replace this folder by an empty umbraco.config file, restart IIS, and you are in bussiness!
