Code signing

[Anton_Huizinga]

Well, since it is adviced to sign your plugins for use in AutoCAD 2016, I have tried to find answers to my questions about this subject. Unfortunately I have even more questions and less answers, so maybe you all can help.

1. In the help files is stated that if you sign your plugin, then it can be loaded from outside the trusted locations and without the security message box. Somewhere else in the help files is stated that you get a dialog with the question to trust or not trust your application when loading. What is true, if I sign my plugin, will it get loaded without any warning dialog? Or do users have to trust it once?

2. Somewhere I've read that the ApplicationPlugins location under "Program Files" is fully trusted. I've tested it with an unsigned plugin, and it works. I've noticed that Autodesk plugins are installed also under "Program Files" or "Program Files (x86)". Is that the new policy to install all plugins there? What is the reason to accept this location with unsigned plugins, and why should we actually use one of the several other locations for plugins? If I change the install path of my plugins to "Program Files", do I have to change it in AutoCAD 2017 again? I don't get the reason about this inconsistent system.

3. If I buy a code signing certificate, I see different prices and different type of certificates. What level or what kind of certificate do I really need? Global Sign has two certificates, Standard and Extended. They compare the Standard with the VeriSign certificate, but I assume they should have compared the Extended variant. The Standard costs $229 and the Extended $410. The VeriSign certificate costs $499. Yearly.

4. Somewhere in the help I've read that AutoCAD can't use strong names. So I cannot use the certificate with strong naming? I cannot set the signing option in Visual Studio but I always need to post process the signing? It is all new for me, so I hope to get some directions 🙂

[CADbloke]

I got mine from http://codesigning.ksoftware.net/. Verisign is fine if you happen to have left your Rolex in your Ferrari at the yacht club because you were too drunk on Moet to dial your chauffeur.

See http://support.ksoftware.net/support/solutions/articles/17170-how-do-i-use-ksign-to-digitally-sign-f... for how to use their code signing tool. Note this is not the same as strong-named signing in the same way that a cat and a catapult should not be mistaken.

As far as I know, the extended Verisign certificate is for signing kernel-mode drivers - no, you don't need it.

[Jeff_M]

I also went with Ksign. Much less $$ than any other solution I looked into, works perfectly and was easy to learn how to use.

[Anton_Huizinga]

Thank you for the link to a cheaper solution 🙂  At least not too expensive to buy for a test.

Still I hope someone can answer the questions about the warning dialog and the bundle location under "Program Files". The help files are not clear about that and Autodesk is placing their plugins in that location too now.

[autodaug · Accepted solution]

In AutoCAD 2015, the warning dialog will pop up if the app is unsigned and outside the trusted locations. If it's signed, then you won't get the warning.

In AutoCAD 2016, it gets more complicated. If the app is outside the trusted locations, whether signed or not, you'll get a warning dialog. But the dialog has an option to say "trust this app", and if you check that then you won't see the warning from that app in the future. (You can also pre-load your certificate into the cert store to avoid the warning the first time.)

About folders under Program Files, those are automatically trusted because they require admin privileges for write (install) access. The idea is that if an app is under there, then it was installed by an admin and can be trusted.

AutoCAD's security mechanisms and recommended practices are still evolving, which no doubt adds to the confusion. We're planning to put out a white paper discussing trusted paths, install locations, etc..

[Anton_Huizinga]

Ah thank you! That is clear now. Hope to see the white paper soon.

[Jeff_M]

---

@autodaug wrote:

 (You can also pre-load your certificate into the cert store to avoid the warning the first time.)

---

Could you elaborate on this? Such as: could a devloper do this within the installer for their app?

[autodaug]

Sure. According to our certificate expert, the MSI installer doesn't inherently support this operation, so you have to do a custom action. One way to perform the custom action is by using either the certutil.exe or certmgr.exe command line tool from Microsoft. For example:

certutil.exe -addstore TrustedPublisher mycertfile.cer

https://msdn.microsoft.com/en-us/library/ms172241.aspx

Another way to do it is programmatically, by calling the Microsoft Crypto API. In .Net, you can use the X509Certificate2 and X509Store classes. This post seems to show good example (C++ is a little messier):

http://stackoverflow.com/questions/1386303/installing-a-certificate-in-a-msi-custom-action-doesnt-wo...

A final note: you should never ship your private key. I.e., you want to distribute .cer files, which can contain only public keys. Don't ship .pfx files, since they may contain private keys.

http://stackoverflow.com/questions/2292495/what-is-the-difference-between-a-cer-pvk-and-pfx-file

[Jeff_M]

Thank you, autodaug! That helped a lot, then I just needed to figure out how to do this within InnoSetup. Following the Answer by SimaWB in this post:
http://stackoverflow.com/questions/12754314/using-inno-setup-how-to-import-a-certificate-cer-file
I got my app working perfectly when installed to the pre-2016 folder (under ProgramData). I needed this since we include user editable text files which cannot be saved when under the Program Files folder.

[Anton_Huizinga]

The person who is responsible for popups was vacationing? 🙂

[Anton_Huizinga]

Since loading unsigned dll files during debug also not works without messages, here a handy tip:

Add the root of your projects to the trusted locations followed by "\..." (three dots). That means all subfolders are automatically trusted.

Example:

[owenwengerd]

There is an important point missed in this thread about code signing: signing code is not what makes it trusted; rather it is signing by a *trusted signer* that makes it trusted. A trusted signer is one whose certificate is signed by a trusted signer. At the root of the chain of signing certificates is a self-signed certificate from a "certificate authority" that is trusted.

You can easily create your own self-signed code signing certificate and sign your code with it, but this does not mean your signed code suddenly becomes trusted. It becomes trusted only when your self-signed certificate is added to the 'Trusted Certificate Authorities' certificate store for the user or the computer on which the code runs.

The reason for buying a certificate instead of self-signing is to take advantage of the fact that Windows ships with a list of trusted certificate authorities pre-installed. Buying a certificate means that your code will be *implicitly* trusted, and doesn't require your own self-signed certificate to be added to the user's certificate store.

Security conscious users should never install "custom" self-signed certificates in their trusted certificates store. As a developer, you should not be asking them to do so unless you are prepared for the liability and responsibility that comes along with being a certificate authority. The moral of the story is that you should cough up $100 per year for a code signing cert from an established certificate authority, and you should *not* be installing certificates on end users' computers.

[Anton_Huizinga]

Well, here you can read how it is adviced to install a certificate:

http://adndevblog.typepad.com/autocad/2015/04/how-to-avoid-trust-this-publisher-dialog.html

Or to install uncertified applications in the Program files location.

I rather use the certificate option, it is also more professional, not only for the plugin as well for the installer.

[owenwengerd]

---

@Anton_Huizinga wrote:

Well, here you can read how it is adviced to install a certificate: 

---

The article explains how to install a certificate, but it does not explain why or when it is appropriate, nor does it recommend to install one.

[CADbloke]

If you're happy to install just any old security certificate on the computer you earn your livelihood with then I'd like to talk to you about my Nigerian bank account...

SERIOUSLY?

Owen is 100% right - if your application tried to install a home-made certificate I would report it as a malware because it IS malware.

[autodaug]

Great point about signing and trust. If a file has a valid digital signature, it doesn't mean that the file is automatically safe or trustworthy. It just means that the vendor was able to buy a certificate from a Certificate Authority and that the file matches what the vendor sent you (hasn't been tampered with). You (the user) have to decide whether you trust that vendor.

I agree that vendors should not try to install self-signed certificates to the Trusted Root store, and that users should not accept any attempt to do so. Windows puts up a warning when this happens, explaining the danger of installing the certificate and recommending that you contact the publisher to confirm the cert's origin. Here's an interesting discussion about what goes into the Trusted Root store:

http://security.stackexchange.com/questions/2268/how-feasible-is-it-for-a-ca-to-be-hacked-which-defa...

About buying a certificate and signing your app so that it's *implicitly* trusted, that is true, but only after your certificate has been added to the Trusted Publishers store. If you don't install your certificate along with your app, and the app is not on the Trusted Path, then the "Trust This Publisher?" dialog will come up the first time that your app tries to load. At that point the user can say yes, causing AutoCAD to add your certificate to the TP store, and they won't see the dialog anymore (i.e. your app is now "implicitly trusted").

There's been some discussion internally about whether we can make this easier for developers who distribute via our App Store. It might make sense to add signing as one of the App Store's services - but it's just an idea at this point..

[Anton_Huizinga]

First of all, I would certainly not install a self-signed certificate. I bought a certificate, and signed the plugin and the installer.

But installed software should work out of the box, most of the clients don't understand security warning dialogs, and are scared to have a virus or something. So they would not continue with the trial software or are suspiciously towards our company.

Autodesk shouldn't have changed the policy to not trust plugin locations suddenly. The security settings are changing every year and are really annoying for developers and for users. First trust plugin locations, now not anymore, but only trust Program Files, why not being consistent and forbid all places?

If Autodesk itself bypass the security settings by installing plugins in the Program Files location, or adding their own locations to the trusted locations, why shouldn't I be allowed to add my installation location to the trusted location, or install my certificate to the trusted publishers store?

As soon as my clients install my software and are forced to trust the installation, why bother them again with new questions to trust the plugin? It is confusing.

[owenwengerd]

---

@Anton_Huizinga wrote:

But installed software should work out of the box, most of the clients don't understand security warning dialogs, and are scared to have a virus or something. So they would not continue with the trial software or are suspiciously towards our company.

---

Autodesk made a bad mistake by showing the warning dialog for implicitly-trusted publishers (that is, signers with a cert that was issued by a trusted certificate authority). Because of the mistake, users will have to manually assert acceptance one way or the other, either when Windows prompts at install time about installing a certificate into the certificate store, or when AutoCAD prompts at runtime. Given those two choices, you should always prefer the latter. The delicate task of managing a certificate store belongs to the user.

[autodaug]

Well, you can get a warning dialog if the installer is not running with admin privilege, or if there is Group Policy in effect to control installing to the cert stores. But otherwise, if we're talking about a normal "Software Publisher" certificate (not a Root or Intermediate CA one), then you should be able to install it to the Trusted Publisher store without causing any warnings or dialogs.

[autodaug]

One more clarification about certificate storage: there are actually two parallel sets of stores. The per-user store is kept under HKCU in the registry and is only available to the current user. The per-machine store is under HKLM and is available to all users, as you'd expect. Administrator privilege is only required when installing to the per-machine store.

Many app installers allow you to select installation for all users vs. for only the current user. It would make sense for your install logic to detect this setting and then add your certificate to the per-machine or per-user cert store, accordingly. Both the certmgr.exe tool and the .Net X509Store API take arguments specifying which store to reference.

If AutoCAD installs your certificate (from the "trust this publisher?" dialog as mentioned above in post #5), it will be added to the per-user store. So admin priv is not required.