code signing without pfx

code signing without pfx

forge5WTUG
Observer Observer
250 Views
0 Replies
Message 1 of 1

code signing without pfx

forge5WTUG
Observer
Observer

New digital signatures no longer come in the pfx format, and it is no longer possible to create these. Even installing a certificate locally is difficult, requiring the use of a hardware lock to be able to sign executables.

 

This means that the old post build event of signtool.exe /f <pfx file> /p <password> /t <timestamp url> MyLoader.dll no longer works.

 

It is unclear of the OneClick built-in signing from visual studio works with dlls (it may only work with exe and only for release builds).

 

There is a 2 line signing command line process that appears to actually sign any exe or dll. Verify confirms that the dll is signed, but no Digital Certificate shows up in the file explorer (unlike the old method with the pfx).

Also, these command lines have to be typed into a developer powershell and so far I have not been able to get them for actually run as a postbuild event in .net 8 core and VS2022.

 

signtool sign /n "<certificate name>" /fd SHA256 "MyLoader.dll"

signtool timestamp /t <timestamp url> /td SHA256 "MyLoader.dll"

 

It is possible that signtool is not found by powershell and you have to supply the entire path to the exe. Also, you cannot put quotes around the signtool path. In my experience doing so will cause the powershell to not understand that sign, timestamp and verify and parameters for the exe. And this command line assumes that powershell is set to the same folder that the dll is in

(i.e. "<path to signtool.exe" sign /n "<certificate name>" /fd SHA256 "MyLoader.dll" will not work from what I could test)

 

Being able to automatically sign the loader dll is convenient, even if only for the many times a day I need to start revit with a debug version of the addin to test something.

 

 

Has anybody manage to get further into automatically signing the loader dll, so that a) we cannot forget to do it for the release version of the addin (which will happen inevitably if we have to manually sign using a tool between a build and creating the installer setup.exe) and b) we can test debug versions without having to confirm every time that we want to run the unsigned addin.

 

0 Likes
251 Views
0 Replies
Replies (0)