Skip to main content
Safe Online Exam encrypts generated .seb configuration files to a configured public X.509 certificate by default. The service holds only the public certificate; the matching private identity is installed exclusively on approved client devices. This page covers the trust model, generating the identity, configuring the service, deploying the private identity to clients, pre-assessment validation, and the full rotation procedure. It also describes the SEB_CONFIG_ENCRYPTION_ENABLED=false compatibility mode and its security trade-offs. This identity is not the service’s HTTPS certificate and is not the LTI JWK. It exists only to let approved SEB clients decrypt generated configuration files and is completely separate from Config Key proof, which protects access-code release after SEB opens the configuration.

​
Trust Model

Each component holds different material and has strict boundaries on what it must never hold: Encryption prevents an unapproved device from opening the configuration. Config Key proof prevents an access code from being released when the running configuration does not match current server settings. Use both controls whenever the instance needs device-restricted configurations.

​
Generate an Identity

The repository generator writes private artifacts under the .local/ directory, which is excluded from version control. Create a protected passphrase file rather than putting the passphrase in a command argument or environment variable:

​
Output Files

The generator produces four files in the .local/seb-certs/ directory:
Immediately move the private PEM, .p12, and passphrase file into approved restricted storage after generation. Remove temporary workstation copies after vault upload and client deployment are verified. Never commit, log, email, attach, or pass these artifacts through command arguments, management-policy parameters, tickets, or chat.

​
Configure the Service

Store the public certificate PEM in Secret Manager and inject it as the SEB_CONFIG_ENCRYPTION_CERT_PEM secret. The Cloud Run installer handles this automatically during ./setup.sh. For manual management, create a new secret version containing the PEM content and update the service revision to reference the new version.
The service reads the certificate at startup and validates it before accepting traffic. Update the secret version reference in the Cloud Run service configuration and deploy a new revision to pick up a rotated certificate.

​
Certificate Validation Requirements

When SEB_CONFIG_ENCRYPTION_ENABLED is unset or true, the service validates the X.509 certificate at startup in hardened runtimes and again when it creates each configuration download. The certificate must satisfy all of the following:
  • A currently valid end-entity certificate (not expired, not a CA certificate).
  • An RSA public key.
  • Key Usage that permits key encipherment or data encipherment.
  • A complete PEM encoding with correct line breaks preserved.
A public-key-only input is a local-development compatibility path and is not accepted as the production trust identity.
The configured public certificate is also available for external verification at:
These endpoints never serve private material. Their x-seb-public-key-hash response header can be compared with the client identity during rollout checks.

​
Deploy the Private Identity to Clients

Use your device-management platform’s certificate or profile mechanism. A well-formed client deployment:
  1. Installs the PKCS#12 identity into the intended device or user scope.
  2. Marks the private key non-extractable where the platform supports it.
  3. Restricts private-key use to the approved SEB application identity rather than all applications.
  4. Prevents profile removal by an ordinary student account when platform policy supports it.
  5. Scopes the profile to a test group first, then to approved assessment devices after validation.
For an MDM-neutral fallback, releases include install-seb-config-identity-user-keychain.sh. Use it only when the MDM can stage the P12 and passphrase in root-owned, mode-0600 files, then run the script as root after the intended user has logged in:
The installer validates the P12 fingerprint and private-key match, validates the approved SEB bundle and Team ID, and performs security import in the active user’s GUI security session. Exit code 75 means a user session, login keychain, SEB installation, or keychain interaction is not ready; retry after that prerequisite is available.Do not pass private material, passphrases, or login-keychain passwords as MDM parameters.
If Jamf School cannot deliver a PKCS#12 payload to the required user keychain, build a signed package fallback on a secured administrator workstation:
Upload the resulting package as an in-house macOS package. Install Safe Exam Browser first, then scope the identity package to a test device group before broader rollout.
If Jamf School policy requires a direct Bash script instead of a package, generate a one-off script locally and upload that generated file only to the restricted Jamf School Scripts area:
The generated script embeds the P12 and passphrase. Never commit it, attach it to a ticket, or give it to a student. This is a lower-assurance fallback; Jamf School role access to the script itself is equivalent to access to the identity.

​
Pre-Assessment Validation

Before each rollout window, confirm:
  1. The active application revision has encryption enabled and the expected public-certificate secret version or mounted file.
  2. The public certificate endpoint responds and the x-seb-public-key-hash header matches the deployed identity.
  3. The client profile reports installed on every intended test device.
  4. On an approved test device, run the application’s setup check and open the encrypted setup configuration.
  5. Config Key proof succeeds after SEB starts.
  6. A device without the client identity cannot open the encrypted configuration.
  7. An unrelated application and an ordinary student account cannot export or use the private key.
  8. The certificate remains valid through the assessment and recovery window.

​
Compatibility Mode

Set SEB_CONFIG_ENCRYPTION_ENABLED=false only for an instance that cannot distribute the private identity to student devices. In this mode the service does not load or use certificate material, and the certificate download endpoints return 404.
SEB_CONFIG_ENCRYPTION_ENABLED=false is a compatibility decision, not an equivalent security posture. The downloaded configuration is no longer restricted to devices holding the client identity. A teacher-set start password still adds SEB password (pswd) wrapping, and Config Key proof remains required and enforced. Use this mode only when managed-client certificate distribution is genuinely not possible for the institution.
When both controls are configured (encryption enabled and a start password set), the service applies inner pswd start-password protection and then the outer certificate-encrypted pkhs envelope. Config Key proof is independent and remains required after SEB opens the file.

​
When to Rotate

Perform routine rotation outside active assessment windows. Rotate the certificate when any of the following apply:
  • The certificate is approaching its expiry date.
  • The private identity is suspected compromised (pause affected assessments immediately).
  • The device-management profile needs to be reissued for operational reasons.
  • Institution policy requires periodic rotation.
Any change to SEB settings invalidates old configuration files. Tell students to download a fresh .seb file after certificate rotation or any protected policy changes.

​
Rotation Procedure

1

Generate and secure a replacement identity

Run the generator script again with a new name or the same name (in a clean directory) to produce a new certificate and private identity. Secure the private artifacts immediately.
2

Create and test the client profile

Create the matching non-extractable, SEB-restricted client profile using your MDM. Deploy it to a test group and complete the full setup check before broad rollout.
3

Deploy the new profile to all intended clients

Allow an explicitly planned overlap period so devices receive the new profile before the service switches certificates. Both the old and new certificates are valid during the overlap.
4

Update the service with the new public certificate

Add the replacement public certificate to the service:
  • Cloud Run: create a new numbered Secret Manager version for SEB_CONFIG_ENCRYPTION_CERT_PEM and deploy a new revision referencing that version.
  • Docker Compose: replace the certificate file at SEB_CONFIG_ENCRYPTION_CERT_PATH and recreate the application container.
Verify the active public-key hash at ${TOOL_URL}/seb/config-encryption-certificate.pem and confirm it matches the new identity.
5

Download and verify fresh configurations

After the service switches to the new certificate, require fresh .seb configuration downloads. Verify that an approved device with the new profile can open the new configuration and that Config Key proof succeeds.
6

Remove the old profile and revoke the old identity

After the overlap and recovery window closes, remove the old client profile from all devices and revoke or delete the old private material from the vault. Do not retain the old private identity longer than necessary.

​
Troubleshooting

​
Next Steps

With the certificate deployed to clients and the service configured, complete the full Canvas and SEB acceptance sequence described in the Testing guide, including a Config Key proof verification on an approved managed device.