Welcome Page (/) URL Handler

The welcome page is the first page new users see when they enter the site at the root level (/). A handler for this page is shown in Listing 2-2.

Listing 2-2  Handler for / URL

world.mount_proc("/") { |req, res|

    res['Content-Type'] = "text/html"

    res.body = <<WELCOME_MESSAGE

<style>

body { margin:40px 40px;font-family:Helvetica;}

h1 { font-size:80px; }

p { font-size:60px; }

a { text-decoration:none; }

</style>

<h1 >ACME Inc. Profile Service</h1>

<p>If you had to accept the certificate accessing this page, you should

download the <a href="/CA">root certificate</a> and install it so it becomes trusted.

<p>We are using a self-signed

certificate here, for production it should be issued by a known CA.

<p>After that, go ahead and <a href="/enroll">enroll</a>

WELCOME_MESSAGE

}

If you used a self-signed certificate above, when the user goes to this page, Safari asks whether you want to trust the server’s SSL certificate. Agreeing allows you to view the page. This is not sufficient for enrollment, however.

Regardless of whether the site certificate is self-signed or not, the enrollment process with the SCEP service also requires the device to trust the custom certificate authority’s root certificate, which means adding the CA root certificate to the device’s trusted anchors list. To do this, you must create a URL handler that provides the certificate with the correct MIME type.

Root Certificate (/CA) URL Handler

The link to /CA in the welcome page provides a means for the user to add the custom certificate authority’s root certificate to the device’s trusted anchors list. This is required for the SCEP stage of the enrollment process.

After Safari on iOS loads the root certificate from that URL, it asks the user for permission to add the new root certificate to the device’s trusted anchors list. (You should access this page only over a secure connection.)

The handler in Listing 2-3 sends the root certificate.

Listing 2-3  Handler for /CA URL

world.mount_proc("/CA") { |req, res|

    res['Content-Type'] = "application/x-x509-ca-cert"

    res.body = @@root_cert.to_der

}

After the user has downloaded the root certificate from a trusted web server over HTTPS, the user can click to continue the enrollment process.

Enrollment (/enroll) URL Handler

Listing 2-4 provides a handler for the /enroll link on the welcome page.

Listing 2-4  Handler for /enroll URL

world.mount_proc("/enroll") { |req, res|

    HTTPAuth.basic_auth(req, res, "realm") {|user, password|

        user == 'apple' && password == 'apple'

    }

    res['Content-Type'] = "application/x-apple-aspen-config"

    configuration = profile_service_payload(req, "signed-auth-token")

    signed_profile = OpenSSL::PKCS7.sign(@@ssl_cert, @@ssl_key,

            configuration, [], OpenSSL::PKCS7::BINARY)

    res.body = signed_profile.to_der

}

The handler above performs very limited authentication to identify the user. The user logs in by sending the word apple as the user name and password over a connection authenticated with HTTP basic authentication. In a production server environment, you should instead tie this code into a directory service or some other account system.

This handler sets the MIME type of its response to application/x-apple-aspen-config, so Safari on iOS treats the response as a configuration profile.

The profile_service_payload function (Profile Service Payload) produces a special configuration that tells the phone to enroll itself in the profile service. The literal string "signed-auth-token" should be replaced with an authorization token from the authentication service that verified the user’s credentials.

Finally, this function signs the profile by calling OpenSSL::PKCS7.sign and sends the signed profile to the device.

Profile Service Payload

The first payload sent to the device (after establishing that it is allowed to enroll) is the profile service payload. This payload is sent by a call to profile_service_payload(req, "signed-auth-token") from the /enroll handler (Listing 2-4).

For a sample profile service payload, see Sample Phase 1 Server Response.

Listing 2-5  profile_service_payload function

def profile_service_payload(request, challenge)

    payload = general_payload()

    payload['PayloadType'] = "Profile Service" # do not modify

    payload['PayloadIdentifier'] = "com.acme.mobileconfig.profile-service"

    # strings that show up in UI, customisable

    payload['PayloadDisplayName'] = "ACME Profile Service"

    payload['PayloadDescription'] = "Install this profile to enroll for secure access to ACME Inc."

    payload_content = Hash.new

    payload_content['URL'] = "https://" + service_address(request) + "/profile"

    payload_content['DeviceAttributes'] = [

        "UDID",

        "VERSION"

=begin

        "PRODUCT",              # e.g. iPhone1,1 or iPod2,1

        "SERIAL",               # The device's serial number

        "MEID",                 # The device's Mobile Equipment Identifier

        "IMEI"

=end

        ];

    if (challenge && !challenge.empty?)

        payload_content['Challenge'] = challenge

    end

    payload['PayloadContent'] = payload_content

    Plist::Emit.dump(payload)

end

This function starts by calling general_payload, which sets the version and organization (these values don’t change on a given server) and returns a template payload that provides a UUID for the profile.

The payload content provides a URL where the device should send its identification (using HTTP POST), along with a list of attributes that the server expects the device to provide (software version, IMEI, and so on).

If an authorization token (representing a user authentication) is passed in from the caller (shown in Listing 2-4), that token is added as the Challenge attribute.

In response, the device sends back the list of requested attributes along with their values. If the server sent a Challenge value in its request, the device also includes this value along with the requested device attributes. Finally, to prove it is an iOS-based device, the device signs this identification with its device certificate. This response is sent to the handler for the /profile URL.

Validate that the device certificate is issued from “Apple iPhone Device CA”, which has the following Base64 encoded PEM data:

-----BEGIN CERTIFICATE-----
MIIDaTCCAlGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJVUzET
MBEGA1UEChMKQXBwbGUgSW5jLjEmMCQGA1UECxMdQXBwbGUgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxLTArBgNVBAMTJEFwcGxlIGlQaG9uZSBDZXJ0aWZpY2F0aW9u
IEF1dGhvcml0eTAeFw0wNzA0MTYyMjU0NDZaFw0xNDA0MTYyMjU0NDZaMFoxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMuMRUwEwYDVQQLEwxBcHBsZSBp
UGhvbmUxHzAdBgNVBAMTFkFwcGxlIGlQaG9uZSBEZXZpY2UgQ0EwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAPGUSsnquloYYK3Lok1NTlQZaRdZB2bLl+hmmkdf
Rq5nerVKc1SxywT2vTa4DFU4ioSDMVJl+TPhl3ecK0wmsCU/6TKqewh0lOzBSzgd
Z04IUpRai1mjXNeT9KD+VYW7TEaXXm6yd0UvZ1y8Cxi/WblshvcqdXbSGXH0KWO5
JQuvAgMBAAGjgZ4wgZswDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLL+ISNEhpVqedWBJo5zENinTI50MB8GA1UdIwQYMBaAFOc0Ki4i
3jlga7SUzneDYS8xoHw1MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly93d3cuYXBw
bGUuY29tL2FwcGxlY2EvaXBob25lLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAd13P
Z3pMViukVHe9WUg8Hum+0I/0kHKvjhwVd/IMwGlXyU7DhUYWdja2X/zqj7W24Aq5
7dEKm3fqqxK5XCFVGY5HI0cRsdENyTP7lxSiiTRYj2mlPedheCn+k6T5y0U4Xr40
FXwWb2nWqCF1AgIudhgvVbxlvqcxUm8Zz7yDeJ0JFovXQhyO5fLUHRLCQFssAbf8
B4i8rYYsBUhYTspVJcxVpIIltkYpdIRSIARA49HNvKK4hzjzMS/OhKQpVKw+OCEZ
xptCVeN2pjbdt9uzi175oVo/u6B2ArKAW17u6XEHIdDMOe7cb33peVI6TD15W4MI
pyQPbp8orlXe+tA8JA==
-----END CERTIFICATE-----

Profile Request (/profile) URL Handler

The handler for the /profile URL is called twice—once to send the device authentication request before the device is allowed to enroll using SCEP, then again after the SCEP step to deliver the final profile to the device.

In this handler, the profile server receives a PKCS#7 signed data payload from the device, which it then unpack and verifies. For a sample of this profile, see Sample Phase 2 Device Response.

To make it easier to follow, the /profile handler is divided into smaller pieces. The first piece of this handler is shown in Listing 2-6.

Listing 2-6  Handler for /profile URL, part 1 of 7

world.mount_proc("/profile") { |req, res|

    # verify CMS blob, but don't check signer certificate

    p7sign = OpenSSL::PKCS7::PKCS7.new(req.body)

    store = OpenSSL::X509::Store.new

    p7sign.verify(nil, store, nil, OpenSSL::PKCS7::NOVERIFY)

    signers = p7sign.signers

If the device signed the request with a certificate that belongs to the hierarchy that issues profile service identities (that is, if this device has enrolled previously), execution follows the first path (shown in Listing 2-7). This path either issues an updated encrypted configuration or, as implemented here, redirects the device to enroll again. For testing purposes, any device that has gotten a profile previously must reenroll.

Listing 2-7  Handler for /profile URL, part 2 of 7

    # this should be checking whether the signer is a cert we issued

    #

    if (signers[0].issuer.to_s == @@root_cert.subject.to_s)

        print "Request from cert with serial #{signers[0].serial}"

            " seen previously: #{@@issued_first_profile.include?(signers[0].serial.to_s)}"

            " (profiles issued to #{@@issued_first_profile.to_a}) \n"

        if (@@issued_first_profile.include?(signers[0].serial.to_s))

          res.set_redirect(WEBrick::HTTPStatus::MovedPermanently, "/enroll")

            print res

By this point, any previously fully enrolled clients have been redirected to the enrollment page to enroll again.

If the code gets past this step, it has received either a list of properties or a new request for a final profile.

In Listing 2-8, the encrypted profile is generated. Because this is part of phase 3 (device configuration), it is included here without further comment, and is explained further in The /profile Handler Revisited.

Listing 2-8  Handler for /profile URL, part 3 of 7

        else

            @@issued_first_profile.add(signers[0].serial.to_s)

            payload = client_cert_configuration_payload(req)

                        # vpn_configuration_payload(req)

            #File.open("payload", "w") { |f| f.write payload }

            encrypted_profile = OpenSSL::PKCS7.encrypt(p7sign.certificates,

                payload, OpenSSL::Cipher::Cipher::new("des-ede3-cbc"),

                OpenSSL::PKCS7::BINARY)

            configuration = configuration_payload(req, encrypted_profile.to_der)

        end

The code in Listing 2-9 handles the case where the device sent its identification. This part should ideally verify that the response was signed with a valid device certificate and should parse the attributes.

Listing 2-9  Handler for /profile URL, part 4 of 7

    else

        #File.open("signeddata", "w") { |f| f.write p7sign.data }

        device_attributes = Plist::parse_xml(p7sign.data)

        #print device_attributes

The next bit of code, Listing 2-10, is commented out with =begin and =end. It shows how you can restrict issuance of profiles to a single device (by its unique device ID, or UDID) and verify that the Challenge is the same as the Challenge value issued previously.

In a production environment, this is typically replaced by site-specific code that queries a directory service to validate the authorization token and queries a database of authorized UDID values for devices owned by your organization.

Listing 2-10  Handler for /profile URL, part 5 of 7

=begin

        # Limit issuing of profiles to one device and validate challenge

        if device_attributes['UDID'] == "213cee5cd11778bee2cd1cea624bcc0ab813d235" &&

            device_attributes['CHALLENGE'] == "signed-auth-token"

        end

=end

Next, the snippet in Listing 2-11 obtains a payload to send to the device that will tell it how to complete the enrollment process. The details of this configuration are described in the discussion of encryption_cert_payload.

Listing 2-11  Handler for /profile URL, part 6 of 7

        configuration = encryption_cert_payload(req, "")

    end

Finally, if this function has nothing to send, it raises an exception that makes the http request fail. Otherwise it signs the profile to be sent and returns it. These bits of code are shown in Listing 2-12.

Listing 2-12  Handler for /profile URL, part 7 of 7

    if !configuration || configuration.empty?

        raise "you lose"

    else

   	# we're either sending a configuration to enroll the profile service cert

   	# or a profile specifically for this device

   	res['Content-Type'] = "application/x-apple-aspen-config"

        signed_profile = OpenSSL::PKCS7.sign(@@ssl_cert, @@ssl_key,

            configuration, [], OpenSSL::PKCS7::BINARY)

        res.body = signed_profile.to_der

        File.open("profile.der", "w") { |f| f.write signed_profile.to_der }

    end

}

After this function sends the configuration to tell the device how to enroll, the device enrolls its identity using SCEP. Then, it sends a request for the /profile URL associated with this handler a second time to obtain the final profile.

The actual payload is described in Configuration Profile Payload and Encryption Certificate Payload. For a sample configuration profile, see Sample Phase 3 Server Response With SCEP Specifications.

The /profile Handler Revisited

Previously, Listing 2-8 showed the encrypted profile generation process. The code in question doesn’t actually run until phase 3, however, so the details were deferred. This section revisits that section of the /profile handler and provides explanation.

The encrypted profile is generated as follows:

• A configuration is generated with a set of configuration payloads. (See Configuration Profile Reference to learn about the contents of these payloads in detail.)

  In this reference implementation, every device gets the same profile. If desired, however, the Challenge information can be used to identify the user requesting the profile, and the code can generate a profile specific to that user.

  Similarly, the device information provided can be used to generate a profile specific to a given device or a particular type of device (for example, providing a different profile for different iOS-based device models).

• The configuration is encrypted with the public key of the device that signed the original request.

• The encrypted blob of data is wrapped in a configuration profile.

The details of this encrypted blob are explained in the descriptions of client_cert_configuration_payload (Listing A-1) and configuration_payload (Configuration Profile Payload).

Listing 2-13  Handler for /profile URL, part 3 of 7 (revisited)

        else

            @@issued_first_profile.add(signers[0].serial.to_s)

            payload = client_cert_configuration_payload(req)

                        # vpn_configuration_payload(req)

            #File.open("payload", "w") { |f| f.write payload }

            encrypted_profile = OpenSSL::PKCS7.encrypt(p7sign.certificates,

                payload, OpenSSL::Cipher::Cipher::new("des-ede3-cbc"),

                OpenSSL::PKCS7::BINARY)

            configuration = configuration_payload(req, encrypted_profile.to_der)

        end