Dear Harry,
Thank you for your query.
I believe you are not officially allowed to use the '2017' word yet.
Will the requirement be for a generic code signing certificate or a trusted certificate?
The former can simply be created using makecert.exe:
http://msdn.microsoft.com/en-us/library/bfsktky3%28VS.71%29.aspx
For more info, I initially searched the Internet for ".net code signing certificate".
That gave me too many results to want to study them in full.
I then added the word "free" to my search and found more useful answers, e.g. on StackOverflow:
http://stackoverflow.com/questions/1177552/code-signing-certificate-for-open-source-projects
http://stackoverflow.com/questions/1482476/code-signing-certificate
They provide a lot of interesting background info without going into too much detail and also point out quite a few certifying authorities.
A few of them provide free certification for open source projects.
I hope this helps.
Please let us know what else you find out about this and which way you decide to go with it.
Thank you!
Best regards,
Jeremy
Dear Harry,
I tried. First of all, here is the current pre-release documentation on this topic:
Code signing of Revit Addins
To improve the security of Revit and its addins, and help users to clearly understand the origin of 3rd party code running within the context of Revit to avoid malicious tampering, a new code signing mechanism has been introduced. All API developers should:
- Get their addins signed with the certificate mechanism provided by Microsoft before the addins are released.
- Get the certificates installed to the Trusted Publishers store of Windows.
If this is not done, one or more message dialogs will be shown during Revit startup:
- If an addin has been signed correctly, but the certificate is not installed in Trust Publisher, a dialog with detailed information of the certificate will be shown.
- If the signature of an addin is invalid, a dialog with an error message will be shown to let end users know this.
- If an addin is unsigned, a dialog with the addin's information will be shown.
In each case, the end user can choose whether they want to always trust the addin, load it once, or skip loading.
Please refer to https://msdn.microsoft.com/library/ms537361(v=vs.85).aspx for detailed introduction about the code signing from Microsoft.
I cannot yet tell from that.
There seems to be quite a lot you can do yourself without help from any commercial or external authorithy, e.g., by manually installing the Authenticode certificates into the Trusted Publishers certificate store on a computer by using the CertMgr tool:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553504(v=vs.85).aspx
The clearest answer will be provided by trying it out, I guess.
Cheers,
Jeremy
Dear Lars,
Thank you for asking.
I am not completely sure myself yet.
The full documentation is provided by the developer's guide in the Revit API help file:
Online Revit 2017 Help
http://help.autodesk.com/view/RVT/2017/ENU
... > Developers > Revit API Developers Guide > Introduction > Add-In Integration > Digitally Signing Your Revit Add-in
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-6D11F443-AC95-4B5B-A896-DD745BA0A46D
Here is some further feedback on handling the signing procedure from another developer that might come in useful and help answer your question:
A. Thank you for the pointer to the updated help. It is useful. That said, I do not find the statement "Once the DLL is signed with an authorised certification, Revit will no longer pop up a security warning dialog upon loading your add-in" to be accurate. Revit still pops a security dialogue after the DLL has been signed but the contents of that dialogue changes. The dialogue informs you that a signed add-in has been found and asks you whether you want to "Always Load" or "Do Not Load". If you select "Always Load" then, of course you are no longer bothered but, until you do, you still get this dialogue even if the add-in is signed.
B. After additional study on multiple workstations I found that I get the security prompt even if I sign the DLL until:
1) I respond "always allowed" to the security prompt (even the one that says that the DLL has been signed) OR
2) You import the certificate into the Windows Certificate Store (Trusted Publishers > Certificates) as described by the Revit 2017 Help article “Make Your Own Certificate for Testing and Internal Use”
Thanks again for pointing to the new help references on this topic.
C. Need to make a correction to my last statement. Further testing and study established that the import of the cert prior to initial launch of the add-in does not suppress the dialogue. The following Help article suggests that this behaviour is by design:
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-900A3EBF-A809-4A0E-96ED-5EEC965A2728
I hope this helps.
Best regards,
Jeremy
Dear Lars,
Thank you for your confirmation and sorry to hear that.
I'll check with the development team whether this is indeed the intended behaviour.
Best regards,
Jeremy
The development team respond:
I’m surprised that pre-loading a certificate does not avoid this message. I thought it did?
If your app’s certificate is already in the windows certificate manager, it won’t show up.
Your installer should add the certificate (.cer) to the trusted publishers using the certutil tool:
http://adndevblog.typepad.com/autocad/2015/04/how-to-avoid-trust-this-publisher-dialog.html
The blog is for AutoCAD but should work fine for Revit, except that Revit intentionally does not support the Trusted Location option.
You can use a custom installer action to add the certificate to the trusted publishers.
I hope this helps.
Cheers,
Jeremy
Another developer asked whether there is any short-cut work-around to avoid the initial prompt to the user for an in-house add-in.
As I suspected, and the development team now confirmed, there is not.
The only way to completely avoid the prompt is to both sign the add-in and push the certification to the domain machines.
Here is the entire Q & A in a little bit more detail, and with some helpful links:
Question: "When Revit 2017 opens with my in-house developed add-in, it prompts the user for an action: always load, load once or do not load. Since the app is in-house developed, I wonder: is it always necessary to have an certificate also for in-house trusted area?"
Answer: The answer is yes, the warning will always be issued. Our security architect adds:
The add-ins must be signed with an approved cert or they will give the popup on first load.
We've documented the process of creating a self-signed cert that can be used for your own internal use:
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-B9A067F4-234F-47F8-A5EE-0D84A93FA98E
You can push the cert to machines in your domain using group policy:
https://technet.microsoft.com/en-us/library/dd807084(v=ws.11).aspx
If you both sign the add-in and push the cert to domain machines, users can use the add-in without the popup.
Cheers,
Jeremy
Revit add-in code signing is intended to reduce the risk of you running malicious code within a Revit add-in. Before discussing it in specific, let's take a step back and look at the current state of technology.
In general, preventing malicious code, commonly called malware, from running on your computer is difficult. The quantity and ingenuity of malware attacks continues to climb. Malware is being used to target everything from hospitals to lightbulbs. It has been used to damage Iranian nuclear facilities, and recently has been thought to be used as a tool to influence the US presidential elections. The best security Revit, or any application, can provide is to not make the situation worse. So we need to look at what techniques Windows provides for keeping your computer secure.
Some of the most important mechanisms that Windows uses to combat malware are:
- User Account Control - This generates the "Do you want to allow the following program to make changes to this computer?" popup you frequently get when installing applications.
- Mark of the Web - This generates a dialog when you try to run applications downloaded by your browser.
- Authenticode - Microsoft's trademarked term for code signing of executables.
Due to the way that Revit add-ins are downloaded and installed, they bypass User Account Control, Mark of the Web, and Authenticode. That is, Revit add-ins open a hole in Windows' malware security. So Revit must add security to fix this security flaw. Creating and fixing such a weakness is common for apps with add-ins. For example Chrome requires extensions to be signed, and Firefox, which comes from a company that tries to epitomize openness, just added mandatory add-on signing on August 2nd, 2016.
To fix this security hole, we've added code signing. Code signing in Revit, like Microsoft's Authenticode, is intended to give the user a timely security question and to provide you with the information you need to make an informed decision. This is very similar to what Windows' User Account Control and Authenticode systems provide.
As a user, when you are given an add-in signature dialog, you know that the add-in you are loading was written by the owner of the certificate, and that it hasn't been modified since it was signed. It is then up to you to determine if you trust that person or not.
While I would love to have a solution that automatically detected add-in safety and just did the right thing, this is the best that we, as an industry, know how to do. Is it perfect: no. But is it more secure than without signing: I think so.
Neil Smithline
Revit Software Security Architect
Dear Neil,
Thank you ever so much for this very clear, succinct and motivating in-depth explanation!
I like it very much and reprinted it in The Building Coder for readability, searchability and future-proofing:
http://thebuildingcoder.typepad.com/blog/2016/09/trusted-signature-motivation-and-fishing.html#2
Cheers,
Jeremy