MYOWNMDM / DOCUMENTATION
Architecture
A separate root of trust. A constrained device issuing authority. Your endpoints.
A dedicated authority for device identities.
Your root or parent issuing CA signs a device sub-CA certificate. myOwnMDM holds the device sub-CA’s software key and uses it to issue endpoint certificates. The parent authority does not need to be online for routine enrolment.
- 01myOwnCA or a suitable parent CA
Signs the device sub-CA request through a separate ceremony. Its private key stays outside myOwnMDM.
- 02myOwnMDM device sub-CA
Software-held RSA signing key. Name constraints permit the configured device DNS suffix, such as devices.example.com.
- 03Device certificates
Credentials for compatible Wi-Fi, VPN, and internal service clients. Relying services validate trust and enforce certificate status.
The issuing sub-CA must use RSA for the SCEP envelope path. Generate its CSR with devica subca gen-csr. Import requires a CA certificate matching the pending private key, name constraints permitting the configured suffix, and a directly signing issuer first in the supplied chain. Your CA signing process must preserve the required constraints.
A self-issued sub-CA is available for lab evaluation. It is a separate trust arrangement from a production sub-CA signed by your established authority. See sub-CA provisioning.
Identity controls at enrolment.
SCEP and REST issuance use the same enrolment service. A token pins the certificate request’s common name and DNS SAN to one device identity. Requests must use a valid signature, supported strong key, and a hostname under the configured device namespace.
Tokens are not consumed after enrolment. They remain usable for the pinned identity until expiry or revocation. Treat downloaded profiles and scripts containing tokens as credentials.
Apple and Windows workflows generate the device key on the endpoint. The Android delivery workflow generates the key on the server and packages it in a password-protected PKCS#12 bundle. Those files need secure delivery and handling.
myOwnMDM publishes certificate status through CRL and OCSP. It does not directly disconnect endpoints or enforce access at a RADIUS server, VPN gateway, or application. Configure and test revocation checking in each relying service.
A self-hosted, single-instance stack.
The application is Python/FastAPI, with a web portal, SCEP, REST enrolment, and revocation endpoints. The Docker stack uses an HTTPS nginx proxy and an internal application service on port 8800. State persists in a dedicated volume.
- SQLite: the default local database.
- MariaDB: optional backend through the bundled Compose overlay or a configured database URL.
- Keys: encrypted software-held sub-CA and service keys; the keystore passphrase and database belong in your protected backup set.
- Connections: endpoints must reach the enrolment and certificate-status URLs. Configured SMTP and syslog collectors require their own connectivity.
myOwnCA signs the trust chain; myOwnMDM operates device identities. myOwnDN monitors public domains independently and does not inspect your private CA or devices.
The application package and command names remain devica and devica-serve, and configuration uses DEVICA_*. Older application screens may display “DeviceCA”. These names are preserved in the guides so examples match the available source.
Planning a deployment?
Talk to EnigmaIS