I am looking at MDM work.
I think the MDM profile created using SCEP on the server cannot prevent deletion.
So I want to install and manage a controlable MDM profile and a generic profile at the same time.
How can I use the screen-capture prevention feature to create a generic profile and then manage the generic profile with the MDM profile?
However, it is cumbersome to install the profile twice.
I thought that after installing the MDM profile, it will automatically install the general profile or move it to the installable screen.
I am curious about the above contents and possible solutions.
Related
We're in the process of moving from on-premise build servers to Azure Pipelines. We produce "shrink-wrap" desktop software so clearly we need to sign all our binaries before releasing. Our current build infrastructure does this using a USB hardware token from GlobalSign, but clearly that isn't going to work when we're doing cloud builds - sadly, clouds are not equipped with USB ports :D
Now, GlobalSign has recently started advertising Azure Key Vault as a key storage option, and they're perfectly happy to sell this to us, but I'm not sure how we'd actually integrate that with our build pipelines (or indeed whether that's even possible).
Has anyone actually made this work?
Code Signing
I've been battling with Azure Key Vault and Azure Pipelines to get our code signed, and succeeded. So here's what I found out.
Critically, Extended Validation (EV) certificates used for code signing are very different animals to 'normal' SSL certificates. The standard ones can be exported as much as you like, which means you can upload it to Azure Pipelines and use it with the standard Microsoft Sign Tool.
However, once an EV certificate is in Azure Key Vault, it isn't coming out in any usual fashion. You must call it from Pipelines using the excellent Azure Sign Tool as discovered by Anodyne above
Get your certificate into Key Vault. You can use any certificate authority you like to generate the certificate, as long as they understand that you'll need an EV certificate, and critically one that has a hardware security module (HSM), and not one with a physical USB key. Any cloud based system like Key Vault will need an HSM version.
To get the permissions to access this certificate externally you can follow this page but beware it misses a step. So read that document first, then these summarised steps, to get the Key Vault set up:
Open the Azure portal, go to the Azure Active Directory area, and create an App registration: put in a memorable name, ignore the Redirect URI, and save it.
Go to your specific Key Vault, then Access control (IAM), then Add role assignment. Type the name of the app you just created into the select input box. Also choose a Role, I suggest Reader and then save.
The Missing Part: Still in the Key Vault, click the Access policies menu item. Click Add Access Policy and add your application. The Certificate Permissions need to have the Get ticked. And the Key Permissions, despite the fact that you may not have any keys at all in this vault, need to have Get and Sign. You would have thought these two would be in the certificate perms...
Go back to the application you just created. Select the Certificates & secrets, and either choose to upload a certificate (a new one purely for accessing the Key Vault remotely) or create a client secret. If the latter, keep a copy of the password, you won't see it again!
In the Overview section of the app will be the Application (client) ID. This, and the password or certificate, is what will be fed to the Azure Sign Tool later on in a Pipelines task.
Handling the actual code signing from Azure requires a number of steps. The following applies to Microsoft hosted agents, although similar issues will affect any private agents that you have.
The Azure Sign Tool needs the .NET Core SDK to be installed, but a version that's at least version 2.x, and since the latest .NET Core SDK is always used, this means as long as the version of Windows is current enough, you don't need to install it yourself. And you can see which version of the SDK is shipped with which Windows agent.
The current Hosted OS version in Azure Pipelines, also called Default Hosted, is, at the time of writing, Windows Server 2012 R2. Which isn't up to date enough. Installing a newer .NET Core SDK to overcome this is a time drag on every build, and although the installation works, calling the Azure Sign Tool may not work. It seems to be finding only older versions of the SDK, and throws this error: Unable to find an entry point named 'SignerSignEx3' in DLL 'mssign32'.
So the easiest thing to do is change your build to use a later OS image. Windows 2019 works like a charm. And there is no need to install any version of .NET Core.
Then create a command line task to install the Azure Sign Tool. You can use a .NET Core CLI task as well, but there is no need. In the task, type this:
set DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true
dotnet tool install --global AzureSignTool --version 2.0.17
Naturally using whichever version that you want.
The DOTNET_SKIP_FIRST_TIME_EXPERIENCE environment variable isn't strictly necessary, but setting it speeds things up quite a bit (see here for an explanation).
Finally, create another command line task and type in the Azure Sign Tool command that you wish to run with. On Windows this would be something like below, note with ^ not / as a line continuation marker. Naturally, see here for more parameter information:
AzureSignTool.exe sign -du "MY-URL" ^
-kvu https://MY-VAULT-NAME.vault.azure.net ^
-kvi CLIENT-ID-BIG-GUID ^
-kvs CLIENT-PASSWORD ^
-kvc MY-CERTIFICATE-NAME ^
-tr http://timestamp.digicert.com ^
-v ^
$(System.DefaultWorkingDirectory)/Path/To/My/Setup/Exe
And in theory, you should have success! The output of the sign tool is rather good, and usually nails where the problem is.
Re-issuing Certificates
If you need to re-issue a certificate, the situation is quite different.
In Azure, go to the certificate and click on it, opening a page showing the versions of that certificate, both current and older versions.
Click the 'New Version' button, probably accepting the defaults (depending on the choices you wish to make) and click 'Create'.
This takes you back to the Versions page, and there will be a message box stating 'The creation of certificate XXXX is currently pending'. Click there (or on the 'Certificate Operation' button) to open the 'Certificate Operation' side page. Once there, download the CSR (certificate signing request).
In GlobalSign, follow their instructions to re-issue the existing certificate. Once it has been re-issued, they will send an email describing how to download it.
Log into GlobalSign again, and after entering the temporary password, open the CSR and copy the whole text (which starts with -----BEGIN CERTIFICATE REQUEST-----) into GlobalSign. Submit it.
Download using the 'Install My Certificate' button. Then in the Azure 'Certificate Operation' side page - use the 'Merge Signed Request' button that to upload the .CER file to Azure. This creates the new version of the certificate.
Disable the old version of the certificate.
Yes, it's able to do this in Azure DevOps Service Build pipeline.
For normal situation, we usually use SignTool.exe commands to sign files. There is also an extension Code Signing in marketplace, which could sign a single file, you could use script to run SignTool.exe commands for multiple files.
So you can export your codesigning certificate to a pfx file, which you then upload as a secure file to Azure Devops secure file storage which makes it available to your builds.
Azure DevOps could store secure files. Check this link for details: Secure files
Azure Key Vault instance is kind of more complicated. We also have an Azure Key Vault task.
Use this task in a build or release pipeline to download secrets such
as authentication keys, storage account keys, data encryption keys,
.PFX files, and passwords from an Azure Key Vault instance.
The task can be used to fetch the latest values of all or a subset of
secrets from the vault, and set them as variables that can be used in
subsequent tasks of a pipeline.
Not sure how GlobalSign will integrate code sign with your environment. Theoretically, it's able to do this. For the detail parts and implementation, you may need to discuss with their pre-sales. Hope this helps.
If anyone else is looking for this and using RBAC, I found these steps essential:
Key Vault Reader on the RESOURCE GROUP
Key Vault Certificates Officer on the KEY VAULT and on the CERTIFICATE
Key Vault Crypto Office on the CERTIFICATE (to use the key for signing!)
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 gather that most developers (except perhaps for larger companies) use self-signed certificates to sign their apk. Since this is required for app installation, the ability to sign your app is available to anyone. Fairly simple to use keytool and jarsigner from Java SDK. However these self-signed certs and associated private keys do NOT guarantee any degree of security unless you can somehow match that certificate with someone you actually trust. There is no ability to revocate these self-signed certificates (no CRL) and there is no "issuer" (since the certs are almost always self-signed) who "vouches" in some way for the identity of the certificate/key holder who signs the code.
So does Andriod platform have or plan to have any ability to prevent installation of apps SIGNED WITH A PARTICULAR SIGNATURE? or to enable settings only allowing installation of apps signed by a cert/key issued by a list of trusted CA (certificate-authorities/issuers) ?
However, there is some security available: In settings/Security you can prevent installation of anything (even signed and manually copied to your SIM) unless it comes from the Play Store, the default setting. Also you might be able to install a User certificate and ONLY allow apps signed by that cert to install (even if from the Play Store?).
I dont think the purpose of these certificates is to ensure an identity as a normal certificate signed by a CA would. As it seems to me the purpose of the certificates is just to have an extra security factor to ensure that the person that published the app for the first time is the one that publishes updates.
Without this someone that hacks your google account would be able to publish malicious updates to you entire user base.
So I would say its basically a two-factor authentication for publishing.
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.
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.