Offical team blog for SSDT, a tool for on and off-premise database development
We are aware of a new issue today where installing SSDT will fail with the following message "A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file." This is due to an issue in the installer verification code with a SHA256 certificate that expired on 10/6/2013 and we are actively working to update the installer. There are two workarounds:
1) You can install the SQL Server 2012 SP1 components separately and the rerun the SSDTSetup.exe installer. The components necessary are SharedManagementObjects.msi (x86 and x64), SQLDOM.msi (x86 and x64) , TSQLLanguageService.msi (x64), SqlLocalDB.msi (x64), SQLSysClrTypes.msi (x86 and x64), and SSDTDBSvcExternals.msi (located here).
2) You can set your clock back to before 10/6 and then run the SSDTSetup.exe installer
User should not be affected if they are doing an update from a previously installed SSDT as the SQL Server 2012 SP1 MSIs should already be present on the machine.
Any idea when we can expect the solution for the issue?
I have tried the option 1, with no success.
I too am awaiting this fix. Option 2 did not work for me. When do you expect this be resolved?
Thanks for the info on workarounds. Option 2 worked great for me.
Thanks for the workarounds. option 2 worked for me as well. I was getting really frustrated with this installation.
Thanks for the tip. I changed my system's date to the 6th of October which then solved my installation issue.
Opt. 2 works, but if automatic clock sync is enabled, network cable must be unplugged during install, otherwise date is immediately updated to current date. (or clock sync settings must be disabled, if policy/domain settings allow for it)
We now have a Visual Studio 2012 version available.
SSDT for Visual Studio 2012: msdn.microsoft.com/.../jj650015
None of the two options above worked for us. We solved the problem by downloading and installing the most current update for root certificates from catalog.update.microsoft.com (search for "Root", other search queries may not return results).
Setting the date back worked for me.
I believe this issue has been resolved now anyway in the latest release.