I'm using electron-builder.
I can see their documentation mention about EV Code signing.
https://www.electron.build/code-signing.html#windows
But it doesn't say in detail HOW.
In docs, it says If you are using an EV Certificate, you need to provide win.certificateSubjectName in your electron-builder configuration.
But what about the CSC_LINK and CSC_KEY_PASSWORD env? Are they not needed?
Using EV cert, the certificate is bound to USB dongle and I can't export it as .pfx or set password.
So what should I do?
I'm answering myself.
You can omit CSC_LINK & CSC_KEY_PASSWORD since EV cert doesn't give you .pfx file and password.
Instead, you set certificateSubjectName in electron-builder's configuration.
Then it will automatically find certificate installed in your machine with that subject name.
When building, an authorization client used by your cert distributer will pop up to ask token password.
Of course, you need to have USB dongle plugged in.
Related
I have few questions regarding Identity certificate in Profile Payload.
Forgive the ignorance, if some questions are basic.
1.) I found that, we can either use SCEP standard or PKCS12 certificate directly for device identification. SCEP is recommended, since private key will be known only to the device. So in case If I am going to implement SCEP server, do I need to maintain the list of Public key of Identity certificates mapped to the device, so that I can use it later for encrypting?
2.) What is the best possible way to implement SCEP server.? Is there any reliable robust methods available to adopt it instead of writing everything on our own?
3.) What if the identity certificate is expired?
As a basic version while playing around, I tried to add my own p12 certificate to the Payload without using SCEP.
I tried to add the base64 encoded p12 certificate in the identity payloadcontent key,as mentioned in some link reference. I got an error
The identity certificate for “Test MDM Profile” could not be found
while installing profile.
identity_payload['PayloadType'] = 'com.apple.security.pkcs12'
identity_payload['PayloadUUID'] = "RANDOM-UUID-STRING"
identity_payload['PayloadVersion'] = 1
identity_payload['PayloadContent'] = Base64.encode64(File.read "identity.p12")
identity_payload['Password'] = 'p12Secret'
When I checked 'Configuration Profile key reference', it was mentioned that I should send Binary representation of Payload in Data.
So I tried,
identity_payload['PayloadContent'] = ConvertToBinary(File.read "identity.p12")
I got,
The password for the certificate “IdentityCertificate” is incorrect
I am supplying valid password for exporting the p12 certificate.
What am I doing wrong?
Answering your question:
1) Do I need to maintain the list of Public key of Identity certificates mapped to the device, so that I can use it later for encrypting?
Yes. You need some kind of mapping. You can do couple of ways:
Just store it in DB a mapping between certificate common name and device UDID.
Make CN contain UDID (I like this method, because it simplifies initial checks)
And as you pointed out you will need public key to encrypt payloads for this device.
2) What is the best possible way to implement SCEP server.? Is there any reliable robust methods available to adopt it instead of writing everything on our own?
There are open source implementation of SCEP. As example jSCEP have it (I used it) and EJBCA have it (I used it too). I saw other implementation (in Ruby and so on). So, you can find an choose something which works with your stack.
3) You need to renew identity certificate before it expeires (the same way as for any other certificates).
4) If your profile doesn't work, I would recommend you to create the same profile in iPhone Configuration Utility and compare with yours. Most of the time, you missed just one tag or something like that (it will take a lot to figure it out without comparing it with working one).
I'm configuring stuff on the provisioning portal for a new app which will use APNS.
When I went to configure the App Id for pushes the web site popped up a dialog saying I had to use Keychain Access and request a certificate from a CA.
However this is a step I've already been through with a previous app, therefore is there any need to do so again? If there's no need, is it still a good idea, and if so why?
If there's no need to generate a CSR again, then I no longer have the CSR file from previously, so is there anyway to recover it?
Certificates belong to hostnames.
If the hostname is the same, yes you can.
If it is a subdomain, and the certificate is a wildcard, yes you can.
If the hostname is different, you can generate a new csr and apply for your new certificate.
For one of my iOS apps I need to check two things:
Is there an active device lock (pass code)
Has the device lock been triggered by the correct authority / certificate (e.g. my own certificate). This is required to assure specific security guidelines.
For the first part of my question I found this answer - which is sufficient for me. How would you accomplish the second part?
Answering my own question.
First of all the correct question is not about validation of a certificate. It's about validation of meta information placed within a configuration profile (which in my case provides security guidelines for the device lock).
You have to create a custom CA and issue one certificate. The issued certificate has to be placed within your app, the custom CA's certificate goes into the configuration profile.
If the configuration profile is installed it is possible to check whether the certificate within the app binary was signed with the root certificate placed in the configuration profile.
It's not the most secure solution, but definitely a way to go.
--
This post put me into the right direction (Apple Developer Account required).
I am working on an Apple MDM server, and actually it is working fine. I have a signature problem, that makes the client complain about the certificate, so now I am interested in how others sign their configuration profiles.
I use java, but any kind of help is welcome, since this is not a particular question on how to implement the code in java, but more on how to correctly sign the configuration profile.
This is how we do it currently:
byte[] data = ...
X509Certificate cert = ...
KeyPair keyPair = ...
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
gen.addSigner(keyPair.getPrivate(), cert, CMSSignedGenerator.DIGEST_SHA1, new AttributeTable(new Hashtable<DERObjectIdentifier, Attribute>()), null);
CMSSignedData signedData = gen.generate(new CMSProcessableByteArray(data), true, "BC");
response.setContentType("application/x-apple-aspen-config");
response.getOutputStream().write(signedData.getEncoded());
We are using a self signed certificate created with the algorithm SHA1withRSA and the key is with RSA and the size is 2048.
Does anyone see a problem with this way of doing it, or are you just doing it differently which maes it work?
And please feel free to post code in other languages than java - it might still help.
I did two things to fix this.
First I changed the certificate to x509 v3 - it was v1. Then I added KeyUsage and BasicConstraints to make iOS accept it as trusted.
The second I did was to add the certificate itself as a CertStore.
These two steps makes the certificate similar to the certificate iPhone Configuration Utility uses.
If you auto-enroll an account for an X.509 certificate in a Windows PKI environment, do you get the same certificate (and, by extension, private key) on every computer in the domain that you log into, or does a different certificate get issued for each computer you log into?
I would expect there would be a single certificate that would appear in the CurrentUser certificate store on each computer you logged into. But this is a matter of dispute and I don't have an environment where I can test it.
Are there any subtleties of configuring the certificate template that affect this? Does not using roaming profiles affect this?
If it matters, I am most interested in how this works for service accounts, but I expect it would be the same as for interactive user accounts.
Our PKI is currently Server 2003. It should be migrated to Server 2008 within a year.
Win2K3 does support something called "credential roaming". I haven't investigated it myself, but did come across a document explaining it: http://technet.microsoft.com/en-us/library/cc700848.aspx