Configuration profile containing VPN payload and certificate chain not working

No it is definitely possible to attach two certificate payloads to an Apple Configurator profile I have done this myself. See below.

You add the first then click on the + symbol in the top right corner of the certificate option and then add the second.

I use XCA under OS X and don't have that option.

You could add a second partition to a Mac and reinstall Yosemite on it for testing purposes. Adding and removing a second partition will not upset the first one as long as you have enough spare space.

If it turns out Apple Configurator is at fault then you need to report it as an issue to Apple. I currently have an open bug-report over a different issue in Apple Configurator and have not yet had a response. Sometimes Apple are more responsive than others. 😕

If you have a developer account you can use the bugreport.apple.com site, otherwise you will have to use the feedback page here - http://www.apple.com/feedback/configurator.html

Any reason you cannot use Profile Manager?

It is not clear from your post but there is one 'gotcha' regarding also including self-signed rootCA certificates in the case you describe.

It is as your probably aware possible to include multiple certificates in a single .cer or .p12 file. You might therefore think the simplest option is to include the self-signed rootCA and the client cert in the same .p12 file. This might work in some situations but apparently will not in this case. You therefore need to start off with a .cer file for the self-signed rootCA and a .p12 for the client cert & private key and add both files to the certificates payload section in Apple Configurator. You should then see it lists two certificate payloads and not one.

Hagen-1 wrote:

Sorry for being unclear:

Of course I could add both certificates to the profile (even adding the certificate chain from a p12-file was working)!

But I couldn't get the VPN tunnel up - this is what "not working" stands for.

When you add your self-signed rootCA to the profile in Apple Configurator does it look like mine? Mine is a self-signed rootCA but is as you can see 'trusted'. This maybe because this certificate is already installed and trusted on the Mac that is running Apple Configurator.

Could you post a similar picture? Concentrate on the rootCA as that seems to be your problem area, expanding the info for the rootCA even if this prevents showing the other cert would be better.

Yes Profile Manager is part of Server.app but that is very cheap to buy. If as it sounds you are a smaller organisation you could look at using the free version of Meraki Systems Manager. I use this myself along with Profile Manager.

See https://meraki.cisco.com/form/systems-manager-signup

Note: I am using Profile Manager to manage Macs, and Meraki Systems Manager to manage iOS devices. In theory both can do both but this approach worked best for my particular needs.

As I mentioned I use Meraki Systems Manager for iOS devices and this is because it allows me to upload a hand edited mobileconfig file which it can then push out. I currently use the old discontinued iPhone Configuration Utility but in principle Apple Configurator would also work for initially creating the mobile config file. Obviously for iOS devices the keychain issue is moot.

Like you I am manually adding VPN-on-Demand rules because for some insane reason Apple never added the ability to define all the officially supported rules to Profile Manager.

However with IKEv2 VPN profiles Apple have changes the rules, you don't have VPN-on-Demand any more instead you have a single setting of 'always on'. I suspect this maybe down to Apple losing a lawsuit against VirnetX. Therefore in theory you don't have to add custom VPN-on-Demand rules anymore if you use IKEv2. In my own case I did however discover a conflict between another rule that Apple Configurator adds to force all traffic to go via the VPN connection - which I want to happen anyway, and the fact that my VPN server already has its own rule set to do this. So I would have to hand edit it to unset that rule. 😟

I suggest you go ahead and log a bug report.

Ok, I was using a different version of Apple Configurator but I am now running the same as yours so my screen looks more like yours now. I was running the Apple Configurator for Yosemite before, you I can see are running it under El Capitan which is a newer version of Apple Configurator. I suppose it could be an issue with the newer version.

From your previous message and especially the fact that if you manually install the rootCA it works it does seem to be down to how this profile is installing that rootCA. Can you try a Yosemite client? Can you try making a profile using the older Apple Configurator under Yosemite? If the issue is that each time the self-signed rootCA is ending up in the login keychain when it should be in the system keychain then this would be the cause of the failure to connect but we then need to look at why it is ending up in the wrong keychain.

I don't know if it was one of your posts but I seem to recall seeing a similar issue of certs ending up in the wrong keychain posted relatively recently. I normally use a MDM solution e.g. Profile Manager or similar to push profiles to clients. The way that Profile Manager works at least is that if the profile is applied to a device or member of a device group then the certs gets put in to the system keychain and this would apply to both the self-signed rootCA and the client device cert. If however the profile is being applied to a user or member of user group then it gets put in to the login keychain. The later would be more appropriate to using a S/MIME certificate.

You have not yet identified the type of VPN you are using but in the case of IKEv2 it is very important to include a Subject Alternative Name (SAN) as well as a common name. It is also the case that currently a hostname will not work as a subject alternative name for IKEv2 on a Mac. I use a dummy email address e.g. serialnumber@domain.com

I use a free tool called XCA which makes creating certificates much easier especially when dealing with Subject Alternative Names. See https://sourceforge.net/projects/xca/?source=directory