Hello Everyone!
I am attempting to code sign my Revit addin and I can not seem to get Revit to recognize it. I have a self signed certificate which I have manually installed into my trusted root authorities, I have built out the addin in visual studio and copied all DLL's and addin file to the addins folder. I have then run the sign tool command:
signtool sign /f "Path/To/codesign.pfx" /t http://timestamp.comodoca.com/authenticode /p "MyPassword" "Path/To/Addins//2018/AppName.dll"
This command executes successfully and if i go into the properties for the DLL I can see a digital signatures tab containing the information I added for my self signed certificate. Yet When I start Revit, it still says it is unsigned...Where did I go wrong?
I have tried various other combinations of this command including passing in the .addin file which errors out saying unrecognized file and signing all dlls in my addins folder.
If you are self signing you have to also be your own certification authority i.e. create one of that nature and add to:
Trusted Root Certification Authorities
Your publisher certificate is derived from this and goes in:
Trusted Publishers
So when you check the certificate under certification path it will say under the status 'This certificate is ok'
This above is for the purpose of testing and for internal corporate IT use. When you publish to app store you can't self sign (I assume).
Hey thank you for your reply.
I have my own certificate authority. I have a .CRT and a .PFX file. I have added both to my trusted root. I have a "digital signatures" tab on my DLL but when revit starts it still says its unsigned.
I can only tell you what worked for me. As noted above I didn't put both certificates in the same store.
Also note that there is a certificate manager for local user and local machine.
certlm.msc (Local machine)
certmgr.msc (Local user)
I have the same arrangement reflected in both but I believe you only need them for one of them (the example in the link is local user).
Gotcha. Maybe its not adding right? It looks like its still having an issue on the windows side but i would imagine revit should still at least show the signing info?
I have hit "view certificate" and added it, I also have the original cert since its a self signed.
No, the details of certificate should be similar to as follows when you look at the properties of the dll file:
When you review the certification path should be similar to below:
You'll note from above I've created two different types of certificates for two purposes. One that is used to create the publisher certificate and one that is used to verify the publisher. You'll normally get a certificate from a CA where they create one from one of those you already have in 'Trusted Root Certification Authorities" (this is the mechanism that makes it work). The full certification path is verified.
Oh I see ok, I think I am beginning to understand. So somewhere in my certificate chain Its breaking down, Presumably because I need to use two different certificates. I will relook at that link you sent and do some additional searching to see how I can go about getting this chain to work properly, I bet that is the issue though!
Perhaps you don't need two but this is how I achieved it and its been working ok since signing was introduced..
I hear people occasionally complaining about publisher warnings reappearing but I've never experienced this using this approach.
Peter Hirn added an automatic signing step to the RevitLookup continuous integration on GitLab:
https://github.com/jeremytammik/RevitLookup/blob/master/.gitlab-ci.yml#L53-L79
script:
- apt-get update && apt-get install -y --no-install-recommends osslsigncode
- mkdir -p .secrets && mount -t ramfs -o size=1M ramfs .secrets/
- echo "${CODESIGN_CERTIFICATE}" | base64 --decode > .secrets/authenticode.spc
- echo "${CODESIGN_KEY}" | base64 --decode > .secrets/authenticode.key
- osslsigncode -h sha1 -spc .secrets/authenticode.spc -key .secrets/authenticode.key -t ${TIMESERVER} -in "${ASSEMBLY}" -out "${ASSEMBLY}-sha1"
- osslsigncode -nest -h sha2 -spc .secrets/authenticode.spc -key .secrets/authenticode.key -t ${TIMESERVER} -in "${ASSEMBLY}-sha1" -out "${ASSEMBLY}"
- rm "${ASSEMBLY}-sha1"
This is great! I am going to utilize that in my own Repos. Ok I finally got windows to recognize my cert, Let me track through what I did and how I got it to work.
Originally I was using openssl on a linux server to generate the certs and private keys. I then used openssl to convert those to a pfx file and was using that to sign stuff, Looks like that does not work too well.
I followed the post in this thread and that worked....To rehash what I did to make this work:
Notes before you begin: MakeCert.exe, pvk2pfx.exe, and signtool.exe are all located in C:\Program Files (x86)\Windows Kits\8.1\bin\x64\ i have already added this to my environment variables, make sure you do so too otherwise you will have to specify in your command where to find these exes
MakeCert.exe -r -sv AVT_CodeSign.pvk -n "CN=AVT" AVTCodeSign.cer -b 01/01/2020 -e 12/31/2020
NOTE: MakeCert is deprecated according to official Microsoft sources, but at the time of this writing that command still works. They have an alternative Powershell commandlet that does the same thing though I did not try that since MakeCert worked for me.
pvk2pfx.exe -pvk codesign.pvk -pi MySecurePassword -spc codesign.cer -pfx codesign.pfx -po MyOtherSecurePassword
NOTE: The passwords can be the same here, The password Im using here is from a prompt from Step 1. That prompt will ask you to supply a password for the private key or give you the option to press "none" Whichever you choose, supply that password in step 2.
Step 3: Use CertMgr.msc to install your codesign.pfx file NOT the certificate. Install it Trusted Publishers, then in Trusted Root Certification Authorities
NOTE: its important here to click your .pfx file as when I did this step, the default was choosing the cert file. Im unsure if this way is better than simply right clicking and hitting "install cert" but it seems both will get you to the same spot.
signtool sign /f "Path\To\codesign.pfx" /t http://timestamp.verisign.com/scripts/timstamp.dll /p "MySecurePassword" "Path\To\RevitAddin.dll"
Following this process I was able to get a valid digital signature, Im not sure why generating it using openssl on linux was causing an issue but there may be something to this method that works better.
Thank you very much for confirming and providing the details of your experience!
I edited and shared them on The Building Coder: