thx for the answer.

I’ve checked the Apple documentation “iOS Configuration Profile Reference” in regards to the PayloadCertificateUUID and did a little messing around with a .mobileconfig
file. It turns out that what I did describe in my first posting (quote: The trick seems to be to have a private key included in the .mobileconfig file and specify this one
as the one to be used with EAS.) is exactly what this PayloadCertificateUUID referencing part does. As soon as I configure the certificate section in the iPCU to include a
private key, a PayloadCertificateUUID is listed in that particular part of the xml code. The next step is to configure the Exchange-ActiveSync part of this config file
(option: identity certificate – data for connection with ActiveSync). Selecting the same private key from the previous step, adds the same PayloadCertificateUUID to the
ActiveSync part of the xml code. Thus, the issue remains because I would need to get the private key off of the device to include it in the .mobileconfig file to be able to link this PayloadCertificateUUID.

What you are describing for Afaria (quote: you can either attach an existing certificate or request a new cert through SCEP. Which means you’ll have one SCEP identity in general for MDM, and another for EAS) got me thinking. Doesn’t that mean that the Afaria system is managing the private part of the key? How else would they be able to do the PayloadCertificateUUID referencing part described above? Is the Afaria system generating the certificate request and passes the private key on to the device? How does
that impact the security of the private key?

I’ll get the Apple documentation for MDM solutions and have a read. Maybe that’ll sched some more light

When I try https://localhost/Microsoft-Server-ActiveSync, I get “Bad Request” as the only response (well after I sign in) in Google Chrome and “This page not found” in IE, but the tab says “HTTP 400 Bad Request”.

The fix for OWA said something about that installing Exchange over an existing (not freshly installed) IIS 7 will not change some of the necessary settings to allow Exchange to work properly. Since I can’t find the article again, I don’t know what changes I need to make in IIS and/or the file system to let this work.

Do you have any other ideas?

Thanks for all of your help (and time) so far.

Tom

The SSTP box is just a plain Windows Server with RRAS? And you installed the CAS role without any errors through the Exchange Setup Wizard afterwards?

While I haven’t atttempted it I could see it being problematic to get SSTP and “plain” HTTPS running on the same IP address. Does it work if you disable SSL for OWA/EAS and run it over HTTP? And similar – does OWA/EAS work with SSL if you disable RRAS? And are you seeing HTTP 400 if you attempt opening up https://localhost/Microsoft-Server-ActiveSync in the browser on the server?

It’s an interesting scenario to attach the SCEP certs to the EAS profile, although I haven’t really gotten around to testing it.

The configuration profile reference state that to attach a certificate to an Exchange payload you need to either attach the certificate as a blob (the contents of a pfx/p12-file) thus including the private key. Alternatively you can use the PayloadCertificateUUID key to reference an identity. I have not checked if there’s a way through iPCU to fetch the UUID required. If you can fetch this UUID you could build a complete EAS profile. Needless to say it would be messy to do mass deployments this way

Using Afaria as a reference implementation, when you build an EAS profile and want to use certificates you can either attach an existing certificate or request a new cert through SCEP. Which means you’ll have one SCEP identity in general for MDM, and another for EAS. Not knowing the profiles being built behind the scenes I don’t know the details, but I’m guessing it’s done this way for a reason.

I don’t know if you’re trying to build it the manual way just for learning purposes, but ready made MDM solutions are easier iPCU doesn’t expose everything the .mobileconfig and .provision files can do as some of it is intended to only do in MDM scenarios where you have a server component controlling parts of the process.

I have been reading your blog for a solution with EAS not talking to iPhone/iPad with a SCEP certificate. In my lab EAS denies communication with such devices and certificates.
My lab setup: all Win2008R2 SP1 Servers, Exchange 2010 SP1RU6, Enterprise CA with SCEP service configured and running and, iPhone4/iPad2 (both iOS5).
I have configured a .mobileconfig file using Apple’s iPCU. It contains the link+dll for the SCEP server, the CA name, a x.500 name with O and CN defined, a valid challenge and both the signature and encryption options are ticked. I’ve also included the Root CA and Intermediate CA certificates in the certificate section of the .mobileconfig file.
The profile installs fine, adding the root and intermediate certificates, generates a key, send the request to the ca and is issued a valid certificate. I then export this certificate and publish it in Active Directory for the user account.
I then setup an EAS account on the iPhone/iPad and configure it for the appropiate user. Communication with EAS fails with the message: ASHTTPConnectionErrorDomain error 403.
I’ve already tried adding Clientauthentication, Secure Email and Encryption to the SCEP template. Still no good.
If I use a certificate issued on the base of the “User” template, include it in the .mobileconfig file, configure the EAS section with the appropiate details and then select the this user certificate to be used for the EAS communication, it all works like a charm.
The trick seems to be to have a private key included in the .mobileconfig file and specify this one as the one to be used with EAS. Using a SCEP certificate requested from the device does not work, as I cannot get the private key from the device into the iPCU on the PC.

Do you have any ideas or suggestions for me?
Thx a lot and sorry about the looong text

Best regards
Chris