views:

581

answers:

1

Hello,

I build a .NET Class Library project that accesses the mshtml.HTMLDocument when called (from JavaScript). Everything works ok on my machine since I changed the permissions in .NET Configuration for Trusted Sites to have Full access.

But for the end users I would like Internet Explorer to prompt them just like, say, Windows Update does.

I singed the assembly with a strong name and with an auto-signed certificate, and I am asserting the Unmanaged code SecurityPermission, but still no 'yellow bar' asking the user.

Does anybody know how to trigger this prompting? Thanks

Later edit : some more details: I am embedding the component as <object classid="dllname.dll#namespace.classname" ><object> and it works, but does not have the security permissions.

If I embed it like <object classid="clsid:..guid.." codebase="dllname.dll#-1,-1,-1,-1"></object>, the permissions to install pop-up comes up but the object fails to instantiate.

Update: I made my class a COM one, implemented Safe-for-scripting, I made a MSI out of it and put it in a .CAB file. It installs, if the user has my certificate in the Trusted Roots, and it works.

It doesn't work however if it is not trusted (no questions to the user, just '..has blocked the following activex from..'. Does that really mean I have to put my money into an SSL certificate?!?

+2  A: 

I'm assuming your question is this: can you force IE to prompt the user to install a (previously unknown) certificate, in order to enable an otherwise signed and safe ActiveX control to be run on a page? (If this isn't your question, comment and I can revise.)

Short answer: no. You'll need to shell out $$$ for code-signing cert from a trusted authority. (which is, AFAIK, different from a regular SSL cert)

Long answer:

From a security perspective, being signed with an unknown certificate is similar to being unsigned, because there's no trusted authority telling the client he can trust that code. And IE's default settings are not to allow unsigned ActiveX controls to be downloaded and used.

If what you're trying to do were allowed, then a savvy attacker could simply create a cert, sign it, and thereby make it easier for users to run their attack code.

There are certainly workarounds, but all involve clients taking action to change their IE settings, or (in an intranet setting) having administrators push out changes to client settings.

Here's some more info on this from TechNet (http://technet.microsoft.com/en-us/library/cc505863.aspx):

Internet Explorer is not configured to trust the certificate authority Anyone, including attackers, can create their own CA and issue certificates. Therefore, Internet Explorer does not trust all CAs by default. Instead, Internet Explorer trusts only a handful of public CAs. If the certificate was issued by an untrusted CA and the website is on the public Internet, the server administrator should acquire a certificate from a trusted CA. If the website is on your intranet, a client administrator should configure Internet Explorer to trust the issuing CA.

Justin Grant
Thanks Justin, you summed it up well. However, I find it a little bit overzealous not allowing unsigned code code at all (not even prompting). I would have prefferred a scary screen like the not-trusted HTTPS screen is, but with the option to ignore. It doesn't exist, does it?
Vlagged
Nope. This scenario is not common enough to warrant a special screen. Also, since there's an easy workaround for a legitimate publisher (go buy a real cert or get your sysadmin to push your cert to clients!), there's little impetus for Microsoft to build special-case UI for this scenario.
Justin Grant