micromdm / scep Goto Github PK

right now the server keeps track of certs in a local folder. Both cfssl and vault have robust PKI APIs that the server can use instead.

when passing ./ paths scepclient fails to generate a private key.

Particularly #46 is a great feature I'd like to use when rolling out to real users.
Is there anything that needs to be done blocking a new release?

Broken in 10.13.4 beta

Notes:

// SCEP uses a single HTTP endpoint with the "operation" param to specify what
// service endpoint is actually necessary.
// It would be useful to have an HTTP handler that checks this flag and proxies
// to a different endpoint instead.

$ ./scepserver-darwin-amd64 ca -init
Initializing new CA
$ openssl rsa -in depot/ca.key -out depot/ca-new.key
Enter pass phrase for depot/ca.key:

scepserver.go sets a default of "" which seems to lead to this undefined behaviour

See http://pki-tutorial.readthedocs.io/en/latest/cadb.html

This would allow us to create a CA with a revocation list and also allow us to manage it (within micromdm or from outside)

Please create a tag for the v1.0.0 release.
https://hub.docker.com/r/micromdm/scep/tags/

server/transport.go fails to build due to this.

Hello,

first of all thank you very much for providing the SCEP client and server. We are trying to use the SCEP server within our project as a test server to test our client against.

Our client is built in Scala on top of jscep, version 2.5.0. It seems that we are running into an issue that is similar to #20 if not the same. We have just begun to analyse the issue ourselves.

The initial code to drive our enrollment is here together with a very simple main line.

The log output from the client is here and the corresponding server output is here.

First we have tried the docker image providing scep version 1.0, then we have built our own docker image based on the current master, but got the same error message.

Any hint to investigate the issue further would be highly appreciated.

Right now we use the pkcs7 defaults, which are DES3 and SHA1.

Add support for multiple certs and default to sha256 instead.

MDM for iOS 10 requires that SHA-1, SHA-256 or SHA-512 being supported as one of CA capabilities from SCEP service or it would regard the authorization invalid.

Hello,
I am trying to get a SCEP server working without the use of Go Kit. I have tried to make it work using the code linked here but it is not working. Is there an example that exists for doing this? I have tried to make it work by using the code in the README.md but have had a problem with the variable csr.Subject (Sent From The Client in The PKIOperation) being blank and so the device (An Apple Mac With a SCEP Profile) is rejecting the returned cert for not matching the CommonName (At least that is what I think the problem is).

We've been using https://github.com/golang/dep in most of the newer repos and I'm looking to transition this project as well.

But I've seen several people incorporate the scep server and client in their projects.
To avoid breaking those scripts we'll do a gradual transition.

First, We'll add a Makefile to build scep. The make deps step will still use glide under the hood for a bit.

About a month after, we'll switch the make deps step to dep.

/cc @GeekBroadway

I have an iPhone installing a configuration profile from my Golang server hosted on heroku.
In the configuration profile, a URL is specified, the iOS SCEP client is supposed to POST the device's info to this URL.
I included the scep library example in README file. The ParsePKIMessage is failing with this error: "pkcs7: attribute type not in attributes".
The POST Request's body has a plist file in it and some unclear characters.

Thanks for the great work on this package! I'd like to suggest either moving the scep package to it's own repo or moving the server, client and cmd packages out of this one. The main motivations for this are:

• reduce code footprint for code & security audit purposes
• enforce strong separation of concerns between scep package primitives and their consumers

Hi,

If ADCS service is stooped or CA is down, then GetCACert and GetCACap request is completed and response is OK. How is it possible??

Thanks,
Mini

Hi,

First of all thanks for the very simple and low-sized sources for this SCEP Client & Server implementation :)

I made an Android native application using the latest (2.4.0) version of JSCEP library and I try to do an enrollment to your Go Scep server. But, I have an issue at some point. Let me describe you a little bit what I'm doing :

1. At first, I initialize a new CA certificate on a Linux server into a depot directory

2. Then, I start the SCEP server this way :
   scepserver -depot depot -port 2016 -challenge=secret

3. Then, in my Android application I'm doing this :

java.security.Security.addProvider(new BouncyCastleProvider());

URL server = new URL(enrollmentURL);
CertificateVerifier verifier = new OptimisticCertificateVerifier();
Client client = new Client(server, verifier);

KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");

keyGen.initialize(keysize);
KeyPair keyPair = keyGen.genKeyPair();

X500Name entity = new X500Name(entityName);

// create a self signed cert to sign the PKCS7 envelope
JcaX509v3CertificateBuilder v3CertGen = new JcaX509v3CertificateBuilder(
         entity, BigInteger.valueOf(1), new Date(
         System.currentTimeMillis()), new Date(
         System.currentTimeMillis()
                  + (1000L * 60 * 60 * 24 * 100)), entity,
         keyPair.getPublic());

JcaContentSignerBuilder csb = new JcaContentSignerBuilder("SHA256withRSA");
ContentSigner cs = csb.build(keyPair.getPrivate());
X509CertificateHolder certH = v3CertGen.build(cs);
JcaX509CertificateConverter conVert = new JcaX509CertificateConverter();
X509Certificate cert = conVert.getCertificate(certH);

// generate the CSR
PKCS10CertificationRequestBuilder crb = new JcaPKCS10CertificationRequestBuilder(entity, keyPair.getPublic());

// set the password
DERPrintableString password = new DERPrintableString(secret);
crb.addAttribute(PKCSObjectIdentifiers.pkcs_9_at_challengePassword, password);

// Send the enrollment request
EnrollmentResponse response = new EnrollmentResponse(null);
try {
       response = client.enrol(cert, keyPair.getPrivate(), crb.build(cs), "NDESCA");
} catch (Exception e) {
       e.printStackTrace();
}

When it comes to the enrol method from JSCEP Client, it generates a PKCSRequest and send it to the Go SCEP Server. But something may be wrong because I have the following error message :

ts=2016-12-21T09:45:31Z caller=service_logging.go:50 component=service method=PKIOperation err="ber2der: Invalid BER format" took=125.352µs

We have some doubts about the compatibility between what is expecting the Go SCEP Server and what we are sending into the HTTP POST Request (we are afraid it's not mapped correctly). Basically, our PKCSRequest is containing :

• the PKCS10 request itself
• a transactionId
• an encoder
• a decoder

However, when we just call the getCaCertificate method, the ca.cert from the depot is correctly returned.
certStore = client.getCaCertificate();

Do you have any idea of what can cause this error ?
Thanks a lot for your insight and you help !

Im setting up a mdm server and I want to use the scep of micromdm. I create the ca.ca and the ca.pem and then run both servers (mdmserver and scepserver)
when the device tries to ask for the certificate its appearing a box " The SCEP server returned an invalid response"
this is showed in the scep console

any idea abt it?
lots of thanks

Currently, the scep package has go-kit as dependency for the sole purpose of logging. This approach has some downsides for consumers of the scep package that aren't also using the server/client implementations:

• consumers may already use an existing, incompatible logging impl. with specific output configurations for their logging setup
• enabling logging and what to log should generally be a function of the application, and not the library. Most of the information logged in the scep package is accessible from the caller, and can therefore be logged from the invoking context

My ideal is that the scep package takes a more Go standard library approach and implement no logging (and ideally panics), and instead rely on returning errors to the caller. Alternatively, if this doesn't work for you, the package could expose it's own local logging interface that consumers can satisfy.

An incomplete implementation exists here.

we want to avoid a potential collision here.

Discovered this today, but the import of github.com/fullsailor/pkcs7 in the scep package is actually an alias to https://github.com/groob/pkcs7/tree/sha256. This alias is only respected when built using dep. We use glide and it pulled the original project and this broke our builds in such a way that would require us to switch over to dep to fix. Although we are considering dep in the future, it seems to me that a library package should not require a specific dependency management solution to work.

Ideally, you could just import your fork @https://github.com/groob/pkcs7 explicitly, until your PR was merged.

Hi there!
It seems like either scepserver doesn't support certificate issuance by the requests from another SCEP client implementations, or I'm missing something important.

When I trying to issue a certifiate with scepclient implementation from this repo, it requests certificates just fine.

But when I trying to use some alternative software (where it is impossible to use client from this repo) I facing some problems.

Here is a part of the server's log (with enabled -debug) when such a client (say, certmonger) tries to issue a cert:

level=info ts=2018-02-21T14:58:09.80919166Z caller=service_logging.go:22 component=scep_service method=GetCACaps err=null took=1.061µs
level=info ts=2018-02-21T14:58:09.809846342Z caller=endpoint.go:186 op=GetCACaps error=null took=656.663µs
level=info ts=2018-02-21T14:58:09.809911737Z caller=logutil.go:70 component=http method=GET status=200 proto=HTTP/1.1 host=[...] user_agent= path="/scep?operation=GetCACaps&message=0"
level=info ts=2018-02-21T14:58:09.941931207Z caller=service_logging.go:46 component=scep_service method=PKIOperation err="asn1: structure error: tags don't match (16 vs {class:1 tag:13 length:73 isCompound:false}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} contentInfo @2" took=67.839µs
level=info ts=2018-02-21T14:58:09.941995663Z caller=endpoint.go:186 op=PKIOperation error=null took=133.181µs
level=info ts=2018-02-21T14:58:09.942030467Z caller=logutil.go:70 component=http method=GET status=500 proto=HTTP/1.1 host=[...] user_agent= path="/scep?operation=PKIOperation&message=MIIK%2BAYJKoZIhvcNAQcCoIIK6TCCCuUCAQExDzANBglghkgBZQMEAgEFADCCBZQGCSqGSIb3DQEHAaCCBYUEggWBMIIFfQYJKoZIhvcNAQcDoIIFbjCCBWoCAQAxggJSMIICTgIBADA2MDExCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdzY2VwLWNhMRAwDgYDVQQLEwdTQ0VQIENBAgEBMA0GCSqGSIb3DQEBAQUABIICAGewWOKoR2yg5%2BFSEgXjsUkjhf32zDD8xgwSIYuvzREHYQPvMyS7QNIMkXdtW546B0Qh8DF5Xo1PeE%2Fhoss3HC%2FaUK8NsDAi61EBJCrWneYkNfL9Z02YKMPXAOJWP4xn9J%2FqWIU6613Uce9C%2BFH9w1w6I5Ym1opMLdlR%2FpNfcoWY4B1YxVjWrVqOi1h7qdNp7WPozz8rD%2BSReXZn%2FF8uX4s8A%2FygFSOLZuM5sDgld%2BZyZoDFgqo2waryxcMeT4xcqGs0n9OlKATx4mOt1uiEuejnMIk3XeK0bKEsO2Ox5pTv%2FoIrL4jD9u7t9Ta%2BUjkVNlMV2hIuNdVTb4G0WlYVcrwbOqoJLFvu02KjULYrXDNjbrgAgJJfEYvMJ4AFuH9WtorhI%2FWCnm6Z1CV1j8HvyPVFwPJ5vhZcmRUz5cXrbEK9Q7PearJUT0hvG7H9baiX6enZ9a3rQ6VPwMZ1maXWFht%2BhXpdVsclJhKsb6D3LdJyolyq3MwsL4JH8D1fNLYGXE91c1zCF0Y9IjwA1caKUN%2BuNLFlY%2FdsMjBmj96l5o%2BR%2F%2Btf%2FGJhek6WcctunZnFVpsJ7d4WOrga%2BIyBgDKEfKh1LpQCXt5FVsI1OkbJkMABzccNKPIjCXHGo6yPh7c0Y5AbEhcLaF2tyZg6Cj7EeiVYBClCaqHPq%2BSV5Hmvf%2FOgMIIDDQYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAiWYzY86ViajICCAujgc09L%2FKA6l8whqIrpljFrOYnrnJw%2B1ar59PkMv7m83fRKoB7axGIqy7YHpKWqZSPjQ5rzDwW1XzwDQR%2Fu%2B%2B%2Bpzj4ZPBTaMtXA1qEuhJV3%2BqCzy5%2BvroQ%2FGVjy9XjGWWiJdBbs7NZlvdL%2B8CtzRI7p0X8I%2By2Pn0EJ0jaGZeI4YP%2B7ihijXSYDBw9LjC%2FFtzyyvxNcomtHpB2VdReqMfMWor8j2lcVeYZLRYCocOfQHaow1n7tm7cNBKqIxGrEA69tXVd7E%2BbFFqRYXX%2B9rvsKRRTdwT9nJ%2FXwbVi7Us0ZkvCQOH8ru%2F31cCsVRMAswstYv9hJ9drGyNvMUVS%2BSV5gL9Sr5ARYGZjZv%2F5LYMZhyAPSdcQfOupnsuVjYkRQEq7PiOqHQnb3peTRbYxdh0tggwwyjbdA551AzX1h4x6z3DhVUL0DcN1Cv%2F1elxlCxtgRtImYTc7kKvuCZAceM7g9ns6TT1PyJXVeHoyfapOYFkKorUWgYBSn%2BDYeKQbE%2Fsk98pSaOT9H9a2K70W6UjVhq%2FOi7zRm6YANEOCFdfkIqXjvhE0D9QWNhN3gePu6jjFcUkbkHmcv0uZHth6WosfyWHYS1l4UP8MGzmiBUoHMwolIZiryeFe2h5EHNoWdKEcc9o4WVzts%2B4XFu%2BAU8UGnMfm4WXaBlqvqsDMydKgNu9I56NebjHB%2B1oVFuAVW3%2BKeFVx34Tq%2F5Myn5B7lkolZgWFafYb2texmpzFLQGAo7JA2q5X02jmShcYtMNUjYKyOFGMetjZSM5nPGuLxedLnsHmuB5Y6H%2FSYxkwmpNzVcEFFm8aGav6QVnitPS2pPrvfYsMgQVUneD7yMf9dgx36pgYWRCUSQr7YuvU8%2B0F6YQ2H1S%2Bz7ei3HCG%2Bg9b7cdidwToM83e5KQz26qNC%2FFb3rXs9DxN0RM1t0lIyeQzbb06ZfuL7l023VxbBvLILq122xHKqKxbhzvcYRRPCGedAU3r%2B6rh%2BpjagggLMMIICyDCCAbCgAwIBAAIgA6AyHuBaREMkvg%2B8vjIFtwYpeHr9J8VPnwkFB%2BmhsOUwDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UEAxMLZnJvbG92LXRlc3QwIhgPMjAxODAyMjEwMDAwMDBaGA8yMTE4MDIyMTAwMDAwMFowFjEUMBIGA1UEAxMLZnJvbG92LXRlc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbf7tK67a0JwnQD1B5mCUljteG%2FCvFC6Wfpe0YtZt0A%2FLL%2B3pXMJjjM50Xy7Xn7k38kVaiEP0m%2FHyc0f9EzOTCnFQ5A6ocZc%2FifiN2WQZ4HbwMSo2XK%2FqXItXzIGy6AdUtfUUpfZxlw0IKOX%2BOWiw80W9ebq8KaINxorY4Ja78hHC6VxctlLvgWZR0poBDMAt61xpROxyMDAbhdwgr%2BWNxWSfRbqANn0%2ByXSKQPXELhgDPC3Kph%2FH%2FHelK%2FB4J7d19VxeTMxE7fmFukfGBbjDeHdUng8vzIFjU7Np0Vdf2MU0RakceCVNKVIri1o%2BAY%2Frr5lEUsIJ%2FxeaIoYFZLQKFAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAIPwYIZh8XxT0cGwqSm5uGC%2BPGzudpD7Kc7kcCrqvp8k0TFgDhG%2BZT8GDPZu6sBP95AIM9cq3nvXrdZWQKoHf9gTBMf1p2g%2BWy3yqK8TgKs0Dw4eDtr2uOKCOtGH7XlumSqL0gVzyxppCDIJJjNFkuNwens1Z9%2FChhqPf408elirfyIsMv4I%2BWNDedoY%2BJmB47bkUqfNTrfQtT7BZ0WzNYlAblPoFdDL85GLkTAOxheqfB2sxyj1NeYPiGyZLZYCaEajrHcDKHau5ioAROtu2Lk%2FdudaSUSCTqKO80EWaU7sTQzrhgcocvwbLdgCojbURevIXaskr1lxIwSyKZAkPUExggJlMIICYQIBATA6MBYxFDASBgNVBAMTC2Zyb2xvdi10ZXN0AiADoDIe4FpEQyS%2BD7y%2BMgW3Bil4ev0nxU%2BfCQUH6aGw5TANBglghkgBZQMEAgEFAKCB%2FTASBgpghkgBhvhFAQkCMQQTAjE5MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIyMTE0NTgwOVowIAYKYIZIAYb4RQEJBTESBBDy5V7qp5Push%2BuXPcHs6nyMC8GCSqGSIb3DQEJBDEiBCCKl6y3xcoXICmrtpxHKqaz73og92Q6l63U91GXetNu1DBcBgpghkgBhvhFAQkHMU4TTDE2Mzk5Nzk5OTU4NTcxNjcwODAxMTIxNTAyMDExMjI0MjEyNDU3NjE0NTI5MjU1MzA4MzU3NDE2NDA3MDc5NTAwODY2MTY4ODc1MjUwDQYJKoZIhvcNAQEBBQAEggEAgiIzhNmI7YY3Dse%2FdACZMNDHmqUDmeDbLoZrVjwDWBj3qoRcfaPkgNqzGOehwQDT19pnTTVq7WxvbrbZG4PaoL%2F5gI3v72xql9dUkIqvLyEKlJLN7yA9x5NeaxI1xy6CsIrxeB%2Bm0uKvCavEHFjTTo%2FvrAgJZ0RIf1dMkLRw3IOToZBRXidbS8kEhT9AJSKWyQCwmypAWdtQcY0brFB4ua7yuPXHpR9K%2BADwocZPgfOjSSjp8tqcrUZCvUtD3IL7ETv5Px6%2F0e%2FeVgF5zpSLSJQ%2FPK6nrJjqIjz1F%2B1XQLEWB78L8AoqATyNP928mo7oELndqjnAdBEEjjnDiXkrEA%3D%3D"

As you can see, server somewhy throws a 500 error instead of successful certificate issuance.

On the client side (certmonger) it looks like:

Request ID '20180221145809':
status: CA_UNREACHABLE
ca-error: Server reply was of unexpected MIME type "text/plain".
stuck: no
key pair storage: type=FILE,location='/root/pki-test3/key.pem'
certificate: type=FILE,location='/root/pki-test3/cert.pem'
signing request thumbprint (MD5): F21ADF60 A76D9342 BE0088F9 2AE5064B
signing request thumbprint (SHA1): 89A1B707 B63A8281 7283BF46 9A4DD55D 7EE47064
CA: test1
issuer: 
subject: 
expires: unknown
pre-save command: 
post-save command: 
track: yes
auto-renew: yes

And there is also glitches with Mikrotik's client:

[admin@MikroTik] /certificate> print detail 
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, 
T - trusted 
0 K T name="testcert1" issuer=CN=tik-test2 common-name="tik-test2" key-size=2048 days-valid=365 trusted=yes 
key-usage=key-cert-sign scep-url="http://12.34.56.78:8080/scep" serial-number="07F48C47E6CD4C55" 
fingerprint="f8add6a69dce5c09268a31b486207d57916f56bc387d88c67d82697a2467252f" 
ca-fingerprint="11d77808b90fb4732a4a45892680d6789a26d8deb47e35d97d82ed70fb3a25f3" 
invalid-before=feb/21/2018 17:55:21 invalid-after=feb/21/2019 17:55:21 challenge-password="secret" 
status="requesting-certificate-failed"

While server logs shows something like that on Mikrotik request:

level=info ts=2018-02-21T15:06:54.474679496Z caller=service_logging.go:22 component=scep_service method=GetCACaps err=null took=1.928µs
level=info ts=2018-02-21T15:06:54.474844924Z caller=endpoint.go:186 op=GetCACaps error=null took=170.369µs
level=info ts=2018-02-21T15:06:54.474908144Z caller=logutil.go:70 component=http method=GET status=200 proto=HTTP/1.1 host=[...] user_agent="Mikrotik/6.x SCEP" path="/scep?operation=GetCACaps&message=DummyCAIdentity"
level=info ts=2018-02-21T15:06:54.586631769Z caller=service_logging.go:34 component=scep_service method=GetCACert err=null took=2.044µs
level=info ts=2018-02-21T15:06:54.58676655Z caller=endpoint.go:186 op=GetCACert error=null took=139.792µs
level=info ts=2018-02-21T15:06:54.58681158Z caller=logutil.go:70 component=http method=GET status=200 proto=HTTP/1.1 host=[...] user_agent="Mikrotik/6.x SCEP" path="/scep?operation=GetCACert&message=DummyCAIdentity"
level=debug ts=2018-02-21T15:07:03.238885117Z caller=scep.go:244 msg="parsed scep pkiMessage" scep_message_type="PKCSReq (19)" transaction_id=317be4cdbb86b220746909e6224bde79bfa5e8a19bf340cc7ebc3ee217a62b61
level=debug ts=2018-02-21T15:07:03.253940734Z caller=scep.go:328 msg="decrypt pkiEnvelope" encryption_algorithm=0 has_challenge=true
level=info ts=2018-02-21T15:07:03.280811676Z caller=service_logging.go:46 component=scep_service method=PKIOperation err=null took=42.113125ms
level=info ts=2018-02-21T15:07:03.280835701Z caller=endpoint.go:186 op=PKIOperation error=null took=42.138907ms
level=info ts=2018-02-21T15:07:03.280881016Z caller=logutil.go:70 component=http method=POST status=200 proto=HTTP/1.1 host=[...] user_agent="Mikrotik/6.x SCEP" path="/scep?operation=PKIOperation&message=DummyCAIdentity"

ex:

scepclient getcaps
scepclient getca
scpeclient getcert

When sending a GET SCEP request, the parameter given in the URL is encoded in base64 (as per https://tools.ietf.org/html/draft-gutmann-scep-10#section-4.1):
"When using GET messages to communicate binary data, base64 encoding
as specified in [2] MUST be used. The base64 encoded data is
distinct from "base64url" and may contain URI reserved characters,
thus it MUST be escaped as specified in [8] in addition to being
base64 encoded. Finally, the encoded data is inserted into the
MESSAGE portion of the HTTP GET request."
However in the implementation the message is not decoded.
Could you please have a look at it?
Thank you!

Building from source code:

./scepclient-darwin-amd64 -server-url=fff --private-key=./self.pem  -challenge=secret
ts=2017-10-13T06:38:47.992627Z level=info op=GetCACaps error="Get http://fff?operation=GetCACaps: dial tcp: lookup fff: no such host" took=8.846073ms
ts=2017-10-13T06:38:47.994655Z level=info op=GetCACaps error="Get http://fff?operation=GetCACaps: dial tcp: lookup fff: no such host" took=1.894425ms
unmatched type or headers

Running from release builds:

$ ./scepclient-darwin-amd64 -private-key client.key -server-url=http://localhost:2016 -challenge=secret
asn1: structure error: tags don't match (16 vs {class:0 tag:20 length:48 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} certificate @2

I'm able to set a challenge phrase for scepserver and request a cert using scepclient with that challenge phrase. However I'm not able to use that challenge phrase to request a cert via config profile. What am I missing? When not using a challenge phrase, the config profile method works fine.

$ ./scepserver-linux-amd64 -depot depot -port 2016 -challenge=testMDM
$ ./scepclient-linux-amd64 -private-key client.key -server-url=http://127.0.0.1:2016 -challenge=testMDM
asn1: structure error: tags don't match (16 vs {class:0 tag:20 length:48 isCompound:true}) {optional:false explicit:false application:false defaultValue: tag: stringType:0 timeType:0 set:false omitEmpty:false} certificate @2

strace reveals :

[pid 14335] write(3, "GET /?operation=GetCACert HTTP/1.1\r\nHost: 127.0.0.1:2016\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\n\r\n", 136) = 136
[pid 14335] read(3, "HTTP/1.1 404 Not Found\r\nContent-Type: text/plain; charset=utf-8\r\nX-Content-Type-Options: nosniff\r\nDate: Wed, 07 Sep 2016 15:23:26 GMT\r\nContent-Length: 19\r\n\r\n404 page not found\n", 4096) = 176

You can retrieve the CA's certificate and check the signature and/or Verify the chain manually but it would be nice if we had an API to do this. Perhaps a Verify method that checks that the cert is valid (not revoked?) and that it was generated by this CA. I know this is typically the duty of a "proper" Certificate Authority system but since micromdm/scep also implements a de facto CA (via the depots) it ought to support this.

What I did:

• CSR with subject /C=US/O=scep-client/OU=MDM/CN=scepclient/[email protected] is passed to the server

What happens:

• Certificate with subject /C=US/O=scep-client/OU=MDM/CN=scepclient is returned

What should happen:

• Certificate with subject /C=US/O=scep-client/OU=MDM/CN=scepclient/[email protected] is returned

Explanation:

In PKIMessage.SignCSR() we pass in the variable template that was generated from the CSR. I see that all the expected subject attributes (in my case C, O, OU, CN, emailAddress) are present in template.Subject.Names (the input). I inspect the output of x509.CreateCertificate and the emailAddress attribute is missing from crt.Subject.Names (only C, O, OU, CN are present, emailAddress is missing).

I tracked this down to the following code in the golang stdlib pkix.Name.ToRDNSequence():
https://golang.org/src/crypto/x509/pkix/pkix.go?s=5216:5263#L193
In this code we see that the library checks for the 9 oids it knows about, then it runs through the list of ExtraNames (there are none in our case, everything is in Names, as returned by x509.ParseCertificateRequest()). However if there were any other oids in Names than the 9 known oids (such as emailAddress), then they are lost.

To me this seems like a bug or a wart in the golang x509 library. I don't have any control over that library, so I've come up with an ugly workaround in scep instead. I haven't put a lot of effort into making it more elegant since I'm not sure it's the direction to go.

Expect a PR soon that shows my workaround. To test this issue, it may be useful to add the -email-address flag to your scepclient, see this patch: syncsynchalt@247ee76

Running the readme example to set up a CA in Docker produces blank files for the key and pem.
docker run -it --rm -v /path/to/ca/folder:/depot micromdm/scep ./scep ca -init

Running the v1.0.0 linux amd64 build locally on Ubuntu produces new keys.

Hello,

It would be very helpful if there was some CRL support in this project to revoke certificates of lost or compromised client machines. Does this currently exist in the project or on the road map?

I understand there are some concerns with CRLs for server certificates, but I'm not sure if the concerns apply for client certificates where only the issuer (and the services of the issuer) need to check the list.

I've been trying to figure out if there's a way to make a certificate as PENDING from the server.

I can see the CSR verifier and can see how I could plug my own there - but this fails the request I can't see how to make it pending indicating I might sign it later (or how I would do that sign, though that I can do with openssl CLI no biggie)

Also do you have any plans for a release soon? Some nice additions.

like here

Use filepath.Join instead.

Three tasks:

1. Switch the asn1 format to a SET.
   openssl:

  346:d=4  hl=2 l=   9 prim: OBJECT            :challengePassword
  357:d=4  hl=2 l=   8 cons: SET
  359:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :foobar
  367:d=1  hl=2 l=  13 cons: SEQUENCE
  369:d=2  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption

micromdm/scep:

  249:d=4  hl=2 l=   9 prim: OBJECT            :challengePassword
  260:d=4  hl=2 l=   6 prim: OCTET STRING      :foobar
  268:d=1  hl=2 l=  13 cons: SEQUENCE
  270:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption

Make sure that parsing a challenge password works after the change.

2. Re-sign the raw csr after adding challenge password. Right now signatures don't match after adding challenge password.

3. Refactor the challenge password code into a new package, add attributions to golang/go and link to open issue.

Currently we get a 500 error if the passwords don't match (due to an early return with error info). The "proper" thing to do is probably to generate a pkiStatus=FAILURE CertRep with failInfo=badRequest set (sadly no specific Challenge failure failInfo).

This feature would allow to pass the full CSR to modules for verification before signing.

The modules would be able to not only verify the challenges, like it is already possible with the challenge stores, but could check the CN, or some other attributes of the signing request.

One module could implement the policy based autosigning scheme of puppet.

Minor tweak to your pre-release notes.

cd scep/testca

should be changed to

cd scep

I would also add a note about downloading the scep binary & making it executable after the git pull.

Other than that you're right "it works!" 👍

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).

I am trying to use the scep library in my Go with Gin Framework server. The deployment to Heroku failed with the following errors:

• scep.go:318:17: p7.EncryptionAlgorithm undefined (type *pkcs7.PKCS7 has no field or method EncryptionAlgorithm)
• scep.go:449:26: too many arguments in call to pkcs7.Encrypt
• scep.go:449:53: undefined: pkcs7.WithEncryptionAlgorithm
• scep.go:542:26: too many arguments in call to pkcs7.Encrypt
• scep.go:542:54: undefined: pkcs7.WithEncryptionAlgorithm

After following the errors, I found out it is related to "github.com/fullsailor/pkcs7" repo.

current image on dockerhub referes to the dockerfile on a202afd revision and doesn't match the current dockerfile and current builds

It is probably an iOS issue. Works on macOS 10.12 and 10.13:

Hardware Model:      iPad4,4
Process:             profiled [310]
Path:                /System/Library/PrivateFrameworks/ManagedConfiguration.framework/Support/profiled
Identifier:          profiled
Version:             ???
Code Type:           ARM-64 (Native)
Role:                Unspecified
Parent Process:      launchd [1]
Coalition:           <none> [235]


Date/Time:           2017-11-09 00:25:30.8494 +0100
Launch Time:         2017-11-09 00:25:21.1574 +0100
OS Version:          iPhone OS 10.3.3 (14G60)
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread:  1

[...]

Thread 1 Crashed:
0   Security                        0x00000001874f7c88 SecCmsAttributeCompareValue + 40
1   Security                        0x00000001874fdd44 SecCmsSignerInfoVerify + 224
2   Security                        0x00000001874fcb88 SecCmsSignedDataVerifySignerInfo + 140
3   Security                        0x0000000187516564 SecCMSVerifySignedData_internal + 336
4   Security                        0x0000000187516800 SecCMSVerifySignedData + 32

This is with a simple CA certificate, initialized with the scepserver:

scep@8bf4586be99b:/var/lib/scep/CA$ openssl x509 -in ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = scep-ca, OU = SCEP CA
        Validity
            Not Before: Nov  8 23:24:05 2017 GMT
            Not After : Nov  8 23:24:05 2027 GMT
        Subject: C = US, O = scep-ca, OU = SCEP CA

The scep payloads look like that:

{"URL": "https://example.com/scep/",
 "Subject": [[["CN", COMMON_NAME]],
             [["2.5.4.5", SERIAL_NUMBER]],
             [["O", BUSINESS_UNIT]]],
 "Challenge": CHALLENGE,
 "Keysize": 2048,
 "KeyType": "RSA",
 "KeyUsage": 5,  # 1 is signing, 4 is encryption, 5 is both signing and encryption
}

I have tried to force an SHA256WithRSA or SHA512WithRSA signature. Works fine on macOS. No Segmentation fault anymore on iOS, but “The scep server returned an invalid response”. HTTPS requests / responses OK on the server side.

Console logs on the iPad:

Nov  9 19:32:34 XXXXXXX Preferences(CoreFoundation)[499] <Notice>: Install profile data, interactive error. Error: NSError:
Desc   : Profile Installation Failed
Sugg   : The SCEP server returned an invalid response.
US Desc: Profile Installation Failed
US Sugg: The SCEP server returned an invalid response.
Domain : MCInstallationErrorDomain
Code   : 4001
Type   : MCFatalError
...Underlying error:
NSError:
Desc   : The SCEP server returned an invalid response.
US Desc: The SCEP server returned an invalid response.
Domain : MCSCEPErrorDomain
Code   : 22013
Type   : MCFatalError
Extra info:
{
    isPrimary = 1;
}

I have to admit, I am a bit lost. Any pointers ?

Please update the Dockerfile to the newest release, and publish to Docker Hub.

Pull Request included at #33

I used the micromdm/scep as a server and the sscep as a client. I cannot enroll the certificate.
root@ubuntu:/home/autotest/workspace/src/github.com/micromdm/scep# ./scepserver -depot depot -port 2016 -challenge=secret -debug -allowrenew 0
level=info ts=2019-01-03T09:03:08.94824173Z caller=scepserver.go:154 transport=http address=:2016 msg=listening
level=info ts=2019-01-03T09:03:28.033250936Z caller=service_logging.go:46 component=scep_service method=PKIOperation err="asn1: structure error: tags don't match (16 vs {class:1 tag:13 length:73 isCompound:false}) {optional:false explicit:false application:false private:false defaultValue: tag: stringType:0 timeType:0 set:false omitEmpty:false} contentInfo @2" took=153.472µs
level=info ts=2019-01-03T09:03:28.033372091Z caller=endpoint.go:186 op=PKIOperation error=null took=280.669µs
level=info ts=2019-01-03T09:03:28.033502567Z caller=logutil.go:70 component=http method=GET status=500 proto=HTTP/1.0 host=127.0.0.1 user_agent= path="/scep?operation=PKIOperation&message=MIIH2gYJKoZIhvcNAQcCoIIHyzCCB8cCAQExDjAMBggqhkiG9w0CBQUAMIIEQQYJ%0AKoZIhvcNAQcBoIIEMgSCBC4wggQqBgkqhkiG9w0BBwOgggQbMIIEFwIBADGCAlIw%0AggJOAgEAMDYwMTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB3NjZXAtY2ExEDAOBgNV%0ABAsTB1NDRVAgQ0ECAQEwDQYJKoZIhvcNAQEBBQAEggIAwDvarhz04E3qM8FZ7JJl%0Anuu6R%2BAL99Pk75mmkBXx8sU8ydcoc1MAJOLrt2Q7VfcbI1txiFH9iuC3HcI%2BT6pI%0AGo6SoWba6spBOBsvf8GpIOtxoCpg%2BCL%2B4Kcc%2BwvfnE%2BsSKGCZ0Rfcovpv9WUIY3O%0Ay9aawowMrRlc5/os4c5T6%2BChdACYsQu%2BvRkBE/fU0mD8bDbUhznpdkK7oquKvDcN%0AcS3qaeNdnPmf0NBNbns1LyrCu1kIIcefcFTNVmzQuBva9VYyMcq9Z9b0Mk76lH4b%0AU1G56VwWBQuSmtUe0vAiz/VZBcsfB9Uq8X8RoKMJodeS7EHHY/J27T8jHkQ1LkcS%0AKiFByedq5gMG%2BJEJNw7T/vN0mGoYBrihLLhGWOmb/1hY%2BZ%2BavoL8Ew734KaKlAQL%0A0VPsctE1Hv7lrw%2Bf1tLl3rv7AuUSJ1g1SD22C/6zwyo8m2QISDVLYG37kwR4Fq6d%0AtDdCc1HjbXmDmxQgEe94AKqZIcXJEQZB8D%2BMz78u/etlXODoOq5%2B%2BGFwbH3e5cM%2B%0ApZnouOoDBoiSBKblKUzRp3YpE6aofIg/bvJW/3JxT9f3c8Qh5ff%2BdeN%2Biv%2BPsBRf%0Arf/tQ8JKN2J/2qNhsEU/s2R0E1MZNMlgGJEf/3j%2BF3/7Qn1YMsUJIgCgBVxFJrfz%0AsHU0FmHYBrtzmDJui7GeaYswggG6BgkqhkiG9w0BBwEwEQYFKw4DAgcECGJ6I/8z%0Ase2jgIIBmHlCMooWSIH9OyK%2BbmycP7nfmxkWKgWS42ziUftHRwVWdYkCY8sC8UWX%0AnAESzr1CPbSd3tcyJX8mD9lO3dcQKO8IvCG2LDjZQ3O8Lcuuqg5RKlrhe6ZinA3e%0ADnuf9X2uAeu3nFk6dMDedMW8gZCwDpln5NednhHgVlib2JTH1/1UhfhFqWeAoxB9%0AoDR9ywLNVupSXM4gMc7vs5dzrKQ0bK2PxSYmGX7nofOQO0fgH1ghFoXXs7pYrCGV%0AIbkSVsl0dvC7asNodVOZTaexb/l5Pgv51Wf%2BopmKTHcBLoRL5IrWJATzFehNlGDg%0ArJfb5KIA59exW77fFswcQkCBVDVGZ6MBN%2B9dMxBQT0TYCrJxJAg6C7SEBJ1d%2BOpH%0ARrl5OCbPlxmCaxZPuMwIMCcp8vpeDG/vFudbzp5mykOZbNQtk/hsPEhn5XispOKB%0AsLIVDoXSjVI%2BHfR00bZcrPzqdZv4wNsBOR5AS5QWwY7qAZaydHp1aA7AwblZPmkX%0ALaSMcEGS/qngWJwiuVCkVfKY9L1ZqS1xGqfJBKs%2Bc6CCAcEwggG9MIIBJqADAgEC%0AAiBFODdEOEQwM0JFRDAwOTI1MkUyREY0MTIxQjcwNDAwRTANBgkqhkiG9w0BAQQF%0AADAVMRMwEQYDVQQDDAoxNzIuMTcuMC4yMB4XDTE5MDEwMzA5MDMyOFoXDTE5MDEw%0AOTExMDMyOFowFTETMBEGA1UEAwwKMTcyLjE3LjAuMjCBnzANBgkqhkiG9w0BAQEF%0AAAOBjQAwgYkCgYEAy58/yfmv7Hd60QbOwZfy4XZy/IRtLQFxXazor0dp0S10gF6Z%0A2LZSlLgxQ3ift2SbV%2Bch4dunNAzSPVmE/QaapY%2BBUPBuvKoQfSYTwFBxlG2YM0yv%0AV1Q87B3r6X45mYyv6z/uUleimf6rA5k1X7Als1fD31uY8B1JpnvJRDv6ZYsCAwEA%0AATANBgkqhkiG9w0BAQQFAAOBgQCS5RqvK0LHpsF/5RGIyF4varZWbgYUzm6ApL0o%0AbaK/qB%2B6ND2TrjldK15NQZKXfFEwke49ERCY6SrQuOZRy%2BEvrRqsNMzsGX6XEDpe%0AZ6Rc6cDtvm4N8PsrqJzV1sXGsspNDTxdf3MeOgV%2BQndSwOR2XD55oZGss35T3wwQ%0A/SPkPjGCAaYwggGiAgEBMDkwFTETMBEGA1UEAwwKMTcyLjE3LjAuMgIgRTg3RDhE%0AMDNCRUQwMDkyNTJFMkRGNDEyMUI3MDQwMEUwDAYIKoZIhvcNAgUFAKCBwTASBgpg%0AhkgBhvhFAQkCMQQTAjE5MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI%0AhvcNAQkFMQ8XDTE5MDEwMzA5MDMyOFowHwYJKoZIhvcNAQkEMRIEEKcBVlQxlxaV%0A8bzQffnlZPwwIAYKYIZIAYb4RQEJBTESBBBkFoZoEAfmzoPeIGqUqvxhMDAGCmCG%0ASAGG%2BEUBCQcxIhMgRTg3RDhEMDNCRUQwMDkyNTJFMkRGNDEyMUI3MDQwMEUwDQYJ%0AKoZIhvcNAQEBBQAEgYB6fCz6AodTiISboDJgd0orslKRVQQRFgQEl32/ioM/hoNb%0AzPucVwKg2TlAudNbUKVPAeY/ak7AVbNpE/vTNCTKaBQEALLSjqyjNGHx8PBGu9ew%0AUGyZi%2BsCZoNQd4Q5IVnkpwL5nzXuQN3D1Fxh1qtPnu5z3EiDJru2EAheA5YKgg%3D%3D%0A"

Having a global PSK is problematic.

Address this by allowing unique PSK for each device.

• allow an external -verify /path/to/script parameter to provide pluggable verification: a user would provide their own validation logic.
• support some build it validation middleware.

https://blog.opentrust.com/?p=312

Supersedes issues #35 and #32

Trying to hit https://MS-CAndes.test.org/certsrv/mscep doesn't successfully complete. Server side, a possibly unrelated error:

The Network Device Enrollment Service received an http message without the "Message" tag.

Error message that's being displayed is https://github.com/micromdm/scep/blob/master/client/scep.go#L95