Use scep without local CA

[ctr49]

How about using the scep daemon without a local CA? Instead plugins could be used to actually issue certificates, i.e. requesting and fetching the cert from a remote CA (that does not support scep).

[groob]

Sure. The entire CA component is a Go interface, with several implementations. If you want to implement the interface feel free to open a PR.

scep/depot/depot.go

Lines 10 to 15 in 0fbc95c

	type Depot interface {
	CA(pass []byte) ([]*x509.Certificate, *rsa.PrivateKey, error)
	Put(name string, crt *x509.Certificate) error
	Serial() (*big.Int, error)
	HasCN(cn string, allowTime int, cert *x509.Certificate, revokeOldCertificate bool) (bool, error)
	}

#2 is a related issue about making the CA pluggable.

[ctr49]

I'll look into it.
For the time being, would it be an option to have an exec statement to an external script that will get the expected function and all parameters of the interface as arguments?

[groob]

We already have approval a via an exec in a recent PR. Take a look at the changes added in master and see is that works first.

If you want to provide a different alternative like the one you describe you can implement the interface and exec a function. We can discuss the code specifics once there's a PR.

[groob]

I meant to link the change by @np5 here #68

[candlerb]

+1 to this, especially if the plugin is able to talk to LetsEncrypt. Then we can get our routers to auto-enrol for free certificates.

The plugin in #68 appears to be for a "CSR validation", so does this need additional work to be able to return the certificate itself?

[candlerb]

I foresee a potential problem. SCEP messages are signed and/or encrypted using the SCEP server's (local) CA cert and key: e.g. in func SignCSR:

        if msg.CSRReqMessage.CSR == nil {
                if err := msg.DecryptPKIEnvelope(crtAuth, keyAuth); err != nil {
                        return nil, err
                }
        }

I worry therefore that a SCEP client might find that the SCEP messages are signed by a different key than the certificate itself, and reject the certificate on that basis.

As it says in the draft:

Some of the SCEP exchanges use unnecessary signing and encryption operations. In particular the GetCert and GetCRL exchanges are encrypted and signed in both directions. The information requested is public and thus encrypting the requests is of questionable value. In addition CRLs and certificates sent in responses are already signed by the CA and can be verified by the recipient without requiring additional signing and encryption.

It's also unclear whether the GetCACert operation would need to return the CA certificate(s) of the third party who is actually doing the signing (e.g. LetsEncrypt), or the local "CA". If it's used to authenticate the messages (draft para 2.2), then I guess it should be the local CA. I note that CertRep may contain additional certificates (3.3.2.1), so the LE cert and chain could be returned there instead; it's not clear if a client would install them.

Hence it probably needs prototyping and testing with a few router vendors and one or more Linux SCEP clients - including the scepclient from within this repo - to see if SCEP can be usefully used this way.

As for the exec API, I guess it's as simple as:

• Receive PEM CSR on stdin
• Return sequence of PEM certificates on stdout (main cert followed by intermediate certs)
• Zero exit on success

Also need to decide whether scepserver will store the certs in depot or not. If it does, then the serial number will have to be extracted from the cert itself.

[groob]

You cannot use something like Let's Encrypt with SCEP.
The certificates and CA we are talking about here are "device identity" or "client certificates". They're used to identify the device for the purpose of authentication to the server, either through mutual TLS or sent as an HTTP header.

Let's Encrypt and other CAs are used as the server TLS certificates which is another use-case/problem.

MicroMDM itself requires three types of x509 certificates to be fully operational.

• a CA for signing device identity certificates. This can be internal or delegated to a SCEP server like micromdm/scep or Microsoft's NDES etc. That is the topic of this issue.
• tls server certs: micromdm already uses let's encrypt as the default option here to requestr/renew certificates
• MDM Push certificate. MicroMDM needs this to authenticate with an APNS topic. You have to go through apple to get one.
• A cert for signing mobileconfig profiles. This needs to be implemented but can also be handled by an external process.

[ctramnitz]

SCEP (in general) can also be used to relay server certificates, not only client certificates.

[jessepeterson]

The SCEP server can now function as an RA (proxy) or with arbitrary issuing CAs with the work from #113 (from issue #112).