ber2der: Invalid BER format

[Vespira]

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 !

[groob]

Hi @Vespira,

Thanks for the detailed bug report.

1. Do you still get the same issue if you choose SHA1withRSA instead of SHA256 in your code?

2. I suspect the issue is with the pkcs7 library. What you're describing sounds very similar to Problems parsing some BER encoding fullsailor/pkcs7#11

If you're able to use a non-production CA and save the CSR as well as dump the HTTP POST body to a file and attach them to the bug report, I can debug further and possibly submit a patch upstream.

[Vespira]

Hello @groob,

1. I just tested it hours ago, and it has no effect. So using SHA256 or SHA1 to create the SignerBuilder does not seems to have an impact on the problem.

2. The error message is located into the PKC7 class of this library, but it is really hard to see what really happening in this class. In the bug CADB enhancements to allow revocation #11 of pkcs7 that you pointed out, fullsailor is saying something that make sense :

Interesting that it detects the compound but doesn't rewrite it. I don't think DER allows compound strings, so that would be why Go's asn1 package won't parse it.

I will try my best to give you details of the communication between my client and server, and to attach these to the issue.

[Vespira]

I tried to use the specific JSCEP Android library (which basically just use spongycastle instead of bouncycastle for crypto operations); but it didn't changed anything, appart from the fact I now can get a 500 Internal Server error from the client after the enrol call.

I made a TCP dump of the exchange between client and server, and also I took a screenshot of the object sent to the SCEP server (sorry I couln't just print it as text, the debbugger didnt allowed this)

tcp_logs.txt

Thanks again for your help on this, it's very appreciated 👍

[groob]

Would you be able to share the actual HTTP Post body saved to a file instead of the TCP log?
I'd like to be able to debug the ber2der code, and would need a ber encoded payload to do that.

[Vespira]

@groob hi again,
Sorry I took time to post HTTP logs because I had some build issue with the app I'm developping the SCEP client on, and I also had hard time installing my HTTP sniffer on Centos (no rpm available on default yum repos, so I had to install a bunch of dependencies and compile 'tcpflow') :

So here is my HTTP file log when I try to call the enrol method.

http_logs.txt

I m also starting to read them, but I'm not sure of what's useful to get here...

EDIT : ok I think I should have a look at the POST at the end, like you said, and maybe also to the HTTP query from the SCEP server, sending a content-type : application/x-x509-ca-cert to the application.

in the POST body, where it tells us it have a content-length of 2777, I observed the first hexdump of the DER encoded certificate, and saw that we have the start SEQUENCE to '30 80'. The ber2der convert method display this error message if a specific byte is equal to 0x80 (I assume this is the byte coming just after the 0x30 indicating the start of the SEQUENCE). Maybe i'm saying a non-sense, I'll keep learning about how it works.

[Vespira]

Hi again,

I'm back to try to solve the issue, the client works fine with your server by the way. If you only want the POST body I can paste it here, but as I was not sure if something is interesting aside, I copied the whole HTTP logs transaction. The POST body seems to be only this:

01R0N060110UUS10U
0+z|U(YFX,JNwl .jN?)}-m-WMzosXIf%_8j[GV[(Xi?S^)PTE~y>DMp4`x<MD8=))>[0*HEI%_&ZifXyhyZa:$ykK+F3:VgZSIB
}u'@,To*Z4vMqE_vs.`n]1C&{t1l*OlKf.+<.Ykx;'?]9xG[nnI9Hh+?96i7#ric<R(B)q
WdD[DChh$",Tgw[[|G{zrt:r~Y4L]$D4uPUzBK!4(Z(<f(vHrny"(,x;k${ts>yAl/rF'V3mN`{
0810U!F'000
scepclient10U
170407105424Z0810U
scepclient10U
0Hep-client10UFR0"0
dHcIasV31BtE*&&ZDN
S:*CSn9jlN+e_UZyDq1z/
|BXIah8_(O<[g,NBD0FN&GQ:-f$Xb7:O.6&50
8o'm:!J[`6pm@UeQ3"t+Xq#]Z$,va/;vp&>IG70(zFJzmkzE=D/a&vh]nPSfD1a0]0=0810U
scepclient10U
0cep-client10UFR0*H
1:PkWINp0 24Z0*H
0800*HW10,*H
w{aJ#!Bwn5b3c5bde020c0505dd6b83e0dee0f37e7526d0
oUE3n='ZmDX}t*zrH9797-010.030.003.043.02016: coz@=Rx4H?<nE3YfnVi+KePzVg~m1#u={nvlE*x((7g:Tvj7

[groob]

hi @Vespira

I can't solve this without a reliable file to test against. Please upload a binary version of the http post body (save it to a file) instead of ASCII text here.

[groob]

I believe this is solved by #38 now. Please reopen if you can reproduce with master version.