I am in the process of developing an application for an organization, and am looking for a sanity check on my strategy, especially given the the nature of the SuperFish nonsense that was exposed.
The users are on a windows domain and the desktop application will be deployed as a ClickOnce application. These deployment packages can be signed so that when the user installs they see it as a trusted publisher rather than 'Unknown Publisher'.
- We will have a self-signed root certificate for internal development (CERT #1)
- We create an application specific certificate signed by that root cert strictly for the purpose of code signing (eku 1.3.6.1.5.5.7.3.3) (CERT #2)
- We use CERT #2 for signing the application
- CERT #1 private key and password is stored securely on site. Only domain administrators (NOT THE DEVELOPERS) have access to the key or knowledge of the key password.
- The public key of the root cert is pushed to the domain as a trusted certificate.
- Developers DO have access to CERT #2 because they need to perform the builds, make deployments.
I don't see any way around giving developers access to the second cert. But in this context, it means third party vendors. On site staff does not have the expertise to take code from developers and do deployments internally. But if you assume that this certificate will leak out over time, then you have to assume that external entities will have the ability to sign code and portray it as 'trusted' to domain members.
Are there any other ideas for making this a secure deployment?
It kills me to teach people to install applications that show up as untrusted, but I'm wondering if that isn't a better option since it will be installed from within the local network, and in fact will in fact usually be installed by IT staff before the newly hired user even starts work.
