Is it acceptable practice to install an Authenticode code signing certificate directly on a build server to create a production signed build? I’m looking for some resources on the net that suggest or support that this practice is legitimate providing you’ve taken appropriate steps to secure the build server and the process by which a build is created and deployed.
All the “best practice” guidance I can find about code signing practices are way over the top in terms of suggested process. Microsoft’s reference document has as many as 6 servers in play for the simple act of signing a single assembly. http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
Some background:
My company creates simple rich-client line of business applications for its employees and direct customers. We do not create commercial software. My build server is physically secured and network secured using my companies strict security policies and procedures. Only very specific people in the organization have the ability to even start a build in my environment.
Our current process requires me to break a build/deploy process into many stages with a lot of manual process in place. We use physical devices to store the Authenticode certificates, requiring user-entered PINs to access. We have to shuffle the assemblies/manifests that require code signing to designated code signing PCs which also have to be physically secured.
To me, it is less secure to pass around a physical token/device and leave all these manual steps in place. There is nothing stopping a person with physical access to the token/device from signing anything they want. At least, with an automated, logged, controlled build server environment, you know what was signed and by who.
The main problem with installing a certificate on a build server and making it accessible to a build account, is that now any developer can sign any malicious piece of code by temporarily commiting it to some legitimate project, and reverting it back after the build.
No matter the actions are logged, the breach is hard to identify or prevent. Especially if development is active and several builds are done per day.
The only solution I can think of is to limit a number of people who can trigger an "RTM" build. Other build types may use a test certificate or avoid signing at all.
In fact, this is the question I bother my head too.
Related
Our company is planning to buy the EV certificate for code signing.
We have automatic builds that should perform the signing, but from what we read, continuous integration tools will not work since the certificate comes with a hardware dongle. I've seen the workarounds, but most of them require either a windows machine or scripting to sign the apps. It feels a lot like a hack.
How do companies that have many products sign their apps, they can't be doing it by hand, can they?
What tools are there to automate the process? I mean there should be some software with an API where you can pass your files and it spits back a signed version of those files. Or something that could split the build process into multiple machines or containers.
How do you guys do it? We're building apps for Windows/macOS.
I came across very little literature to use code signing certificates without a private key being exported. Hence, requesting some basic info regarding including the code signing certificate in the installshield 2013 to sign our setup.exe file.
So it goes like this...
We had a certificate from Symantec and/or Verisign that expired a few days ago. So we got a new certificate from them which is a SHA-256 cert. However, they won't release the private key. Hence we cannot generate a .pfx file which used to include in our installshield. They say that, here on who ever wants to do the code signing using installshield needs the dongle attached to the computer to get the private key verification done. I don't quite understand what they mean. However, it is clear that they want us to connect with the dongle for private key verification. So if I do not have the pfx file, how can I achieve code signing using installshield 2013? I also read on the Web that the support for SHA-256 certs was not available in 2013 and that one would have to migrate to 2015 or above to do something of that sort. So we have hit a roadblock with this thing and our automated build process is failing.
Hence, request you to provide me any pointers as to how can we get this thing done.
Thanks and Regards,
Bhushan.
InstallShield 2015 or so added support for signing using certificates from certificate stores. Before that, some people have intercepted the call to signtool, implementing their own calls to either the real signtool or the APIs it calls. This should give you the freedom to use your dongle-based private key, or anything else you need.
(On the downside, InstallShield 2015's and later implementation doesn't let you do this interception trick.)
Ok...So it goes like this...We have a rights issue. As per Symantec, only the person who is the owner of the certificate, can generate a private key on his machine with his admin privileges and that too using IE 11 browser. Now the issue is, the certificate request goes to a helpdesk portal, pending an approval and then forwarded to symantec after the necessary approval. Looks like the approver has to act as the owner, even though the requesting team has paid for the certificate. That is weird but true. So the person who receives all the certificates first hand has to download the certificate, export the certificate along with the private key into the .pfx file and then send us the .pfx! Meanwhile, is there any possibility that I run the export certificate wizard from the browser and the export .pfx option is disabled just because the user launched the browser with insufficient privileges? How may I confirm that this is a rights issue? Thanks.
Further to these, I simply have a very general question about signing. The thing is, even though I know what code signing is and some of the applications might absolutely need it, I do not see a substantial need for the windows based desktop applications. I may be wrong on this. However, all the literature I see points to the fact that the authority that is publishing should be trusted. Now we as a team are responsible for a suite of desktop applications that are being packaged using installshield and code signed by Symantec SHA 256 class certificates. We only sign the set.exe file and as a result it shows a typical trust prompt to the user who installs our software. Our users are a rather closely knit group of clients and are easily approachable. Also, I do not see a risk of our network being intercepted and hacked to tamper the content of setup. In such a situation, is having a certificate justified?
I have a few questions with respect to SignTool as well. I understand that the signing for our certificate is currently failing because we have not yet procured the private key for it. However, the timestamp verification is also failing for a self signed certificate that I have generated for testing purposes. So I need to understand what exactly is a timestamp doing in installshield when Signtool is invoked? Installshield is a good product; however the supporting documentation provided by Flexera is rather pathetic. Thanks.
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.
I work at a company who does 3rd party iOS development for various enterprises. I've been tasked with researching a better way to build and deploy code to these enterprises. Based on the Apple TOS, they cannot use an application signed with our Enterprise certificate (they're not "in house"). The code needs to be signed with their (our clients) Enterprise certificate. Here are a few possible solutions I've seen -
1) Send the code to the client, and have the client build it. This is a no-go.
2) Create a library with the application code and send the .so file, and the headers, to the client for building. We're currently doing it this way but are looking at making this easier on the client/us.
3) Have the client send us their certificate, mobileprovision, and .p12 file and then we build the application using their certificate. This could work but could become a management nightmare.
We've come up with an idea that is kind of a mix of these ideas. The idea involves building a customer portal where the client can upload their files (cert, p12, provision) to our Mac server and the Mac will automagically build their application, properly signed. The problem I'm having, however, is I can't seem to find out how to automate the installation of certificates and provisions.
So with that said, does anyone know of a way to install a CodeSign certificate (with a .p12 file) and a mobile provision file from the command line? Once installed is there also a way to remove the items from the command line?
Any help, ideas, and/or input would be greatly appreciated. Thanks!
You should be able to manage those resources in the keychain using the security (http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/security.1.html) command. The script I'm using to control command line builds might be a useful reference: https://gist.github.com/949831
Admittedly I've only ever had a maximum 2 external clients plus my own stuff at one time, so it was mostly only the same nightmare that it usually is by default, but how bad would it be if you had to manually do everything EXCEPT the provisioning profiles? In my experience once the client certs got added I never really messed with them again even with new projects (from the same clients.)
You could handle the provisioning profiles by simply copying the files into ~/Library/MobileDevice/Provisioning Profiles, and deleting them when no longer needed. It sounds like you are already set up to automate that process.
If you're currently installing the provisioning profiles by "dropping them onto xcode" I'd suggest you do it by copying into the folder anyway, because then the file names are preserved and so you actually can tell what you have installed by simply looking at the folder.
We will be embarking on an Application developement project (.NET 3.5) for a large organization. As we started thinking about the upgrades we would be giving across the machines, we are looking at options like ClickOnce.
What we need is a push model, as long as the client machine is connected to the network, the server can send updates. I believe ClickOnce is a pull model(although by specifying minimum version we can kind of push). Also ClickOnce downloads complete files only, it cannot download the change (byte difference) among the files.
Can anyone point me to a better tool that can be used here. Also better strategies, if any, are welcome, we are in a very early stage of the project.
I don't have a definitive answer on better options, but I've used ClickOnce and can offer some advice.
There are several update options with ClickOnce (before starting, after starting, check every time, check every X Hours/Days/Weeks, etc). You can also throw those out and write code to check for updates. It's not a "push" from the server, but your client could poll for updates which would be the next best thing. Just remember, the application is going to have to restart after the update to see changes.
ClickOnce only downloads changed files. However, the progress dialog always shows the entire size of the application even if it's only downloading a single file. Everyone worries about that, but it's just a bug with the progress dialog.
Finally, I'm a big fan of keeping it simple. It's really easy to over-think these things and create a monstrosity that was never needed. We went through something similar at my company. We were so worried about users downloading unnecessary bytes, we broke our apps up into more, smaller assemblies. It turned into a nightmare; apps were harder to maintain and performed worse on the client. We finally undid it all and wasted weeks just to end up where we started.
I'm not saying you don't need the features you're asking for, I don't know your scenario. Just educate yourself first and know what you're getting yourself into.
We use clickonce at my company (about few hundred users for the app geographically dispersed). By specifying the minimum version we can make sure that every app installation gets updated after deployment automatically. You are right that clickonce downloads full files only but only files that have changed since previous version. If that is still a concern you can break your application into more smaller assemblies. I think you can also use netmodules but then Visual Studio has not built in support for that.
In general clickonce has worked good for us.
I am just in the process of implementing such a service on top of my distributed application platform. In essence I have developed a "push" model for corporates that follows these basic principles:
Software upgrades are "managed" from the server, NOT from the client, which is in line with the deployment of corporate software as opposed to user software (this is a very important point)
Software upgrades can be customised per client application on the server, i.e. the server can deploy unique configurations to every client if required
Software upgrades can be deployed to clients at different times, or all at the same time, or any combination of the two
The software upgrade version can be specified per client, i.e. different versions can be deployed to different clients as required
All software upgrades for all clients can be "managed" from a single server, i.e. the software upgrading "service" is consistent across any application, and all applications can utilise the software upgrading "service"
Clients can implement a software upgrade policy of automatic (application restarts as soon as the upgrade has been downloaded and available at the client), manual (application needs to be "sent" a custom "force upgrade"
message"), or on restart (application upgrades on shutdown if an upgrade has been downloaded and is available)
All auto-upgrading functionality is transparent to any running applications as this is all performed in autonomous background threads and all inter-process communication and file transfer is handled by my framework
In essence this now allows me (or will allow me when I have tidied a few things up and thoroughly tested the implementation) to manage the version of any application developed by me from a central server after it has been initially installed, without any client intervention.