Problem with client certificate request for TLS server

[Martin Körper]

Hi,

I'm new to bouncycastle and have a problem with creating a valid client
certificate request.

I tried something like this (bouncycastle for java, v1.50):

import java.security.cert.X509Certificate;
import org.bouncycastle.crypto.tls.Certificate;
...
public class ClientAuthTlsServer extends DefaultTlsServer {
private Vector<X500Name> clientCAs = null;

public void setClientCAs(Vector<X509Certificate> rootCerts)
{
clientCAs = new Vector<X500Name>();

for(X509Certificate cert : rootCerts)
{
try {
Certificate tlsCert = parseBcTlsCertificate(cert.getEncoded());
clientCAs.add(tlsCert.getCertificateAt(0).getSubject());
}
catch (Exception e) {

}
}
}

private Certificate parseBcTlsCertificate(byte[] derEncodedCertificate)
throws IOException
{
X509CertificateHolder certHolder = new
X509CertificateHolder(derEncodedCertificate);
return new Certificate(new org.bouncycastle.asn1.x509.Certificate[]
{certHolder.toASN1Structure()});
}

@Override
public CertificateRequest getCertificateRequest()
{
return new CertificateRequest(new short[] {
ClientCertificateType.rsa_sign }, null, clientCAs);
}
}


This always results in a malformed packet.

I analyzed the problem using wireshark and tracked it down to
org.bouncycastle.asn1.DERSequence
.encode, line 88:
out.write(BERTags.SEQUENCE | BERTags.CONSTRUCTED);

Somehow this is written to the stream where the length of the subsequent
DN is expected instead (at least by wireshark).

So my question is:
Am I doing something wrong or is this a bug maybe?

Thanks in advance for your help.

Regards,
Martin Körper

[Lothar Kimmeringer]

Hi Martin,

Post by Martin Körper
for(X509Certificate cert : rootCerts)
{
try {
Certificate tlsCert = parseBcTlsCertificate(cert.getEncoded());
clientCAs.add(tlsCert.getCertificateAt(0).getSubject());
}
catch (Exception e) {
}
}
}

Why do you do you recreate the certificate by converting it to
a byte-array before you add the subject-name to a list? You
already have the certificate, so calling getSubject should already
work there. I'm not sure what X509CertificateHolder is, but it
surely is not an X509Certificate, so it's ASN1-data is most likely
different explaining the error-message.


Cheers, Lothar

[Peter Dettman]

Hi Martin,
This is indeed a bug in the way the certificate_authorities field of a
CertificateRequest is encoded. We've fixed this and added test coverage;
it will be included in the imminent release of 1.51.

Thanks for the report,
Pete.

Post by Martin Körper
Hi,
I'm new to bouncycastle and have a problem with creating a valid
client certificate request.
import java.security.cert.X509Certificate;
import org.bouncycastle.crypto.tls.Certificate;
...
public class ClientAuthTlsServer extends DefaultTlsServer {
private Vector<X500Name> clientCAs = null;
public void setClientCAs(Vector<X509Certificate> rootCerts)
{
clientCAs = new Vector<X500Name>();
for(X509Certificate cert : rootCerts)
{
try {
Certificate tlsCert =
parseBcTlsCertificate(cert.getEncoded());
clientCAs.add(tlsCert.getCertificateAt(0).getSubject());
}
catch (Exception e) {
}
}
}
private Certificate parseBcTlsCertificate(byte[]
derEncodedCertificate) throws IOException
{
X509CertificateHolder certHolder = new
X509CertificateHolder(derEncodedCertificate);
return new Certificate(new
org.bouncycastle.asn1.x509.Certificate[]
{certHolder.toASN1Structure()});
}
@Override
public CertificateRequest getCertificateRequest()
{
return new CertificateRequest(new short[] {
ClientCertificateType.rsa_sign }, null, clientCAs);
}
}
This always results in a malformed packet.
I analyzed the problem using wireshark and tracked it down to
org.bouncycastle.asn1.DERSequence
out.write(BERTags.SEQUENCE | BERTags.CONSTRUCTED);
Somehow this is written to the stream where the length of the
subsequent DN is expected instead (at least by wireshark).
Am I doing something wrong or is this a bug maybe?
Thanks in advance for your help.
Regards,
Martin Körper

[Martin Körper]

Hi Pete,

thank you very much! Works well now :)

Regards,
Martin

Post by Lothar Kimmeringer
Hi Martin,
This is indeed a bug in the way the certificate_authorities field of a
CertificateRequest is encoded. We've fixed this and added test coverage;
it will be included in the imminent release of 1.51.
Thanks for the report,
Pete.

Post by Martin Körper
Hi,
I'm new to bouncycastle and have a problem with creating a valid
client certificate request.
import java.security.cert.X509Certificate;
import org.bouncycastle.crypto.tls.Certificate;
...
public class ClientAuthTlsServer extends DefaultTlsServer {
private Vector<X500Name> clientCAs = null;
public void setClientCAs(Vector<X509Certificate> rootCerts)
{
clientCAs = new Vector<X500Name>();
for(X509Certificate cert : rootCerts)
{
try {
Certificate tlsCert =
parseBcTlsCertificate(cert.getEncoded());
clientCAs.add(tlsCert.getCertificateAt(0).getSubject());
}
catch (Exception e) {
}
}
}
private Certificate parseBcTlsCertificate(byte[]
derEncodedCertificate) throws IOException
{
X509CertificateHolder certHolder = new
X509CertificateHolder(derEncodedCertificate);
return new Certificate(new
org.bouncycastle.asn1.x509.Certificate[]
{certHolder.toASN1Structure()});
}
@Override
public CertificateRequest getCertificateRequest()
{
return new CertificateRequest(new short[] {
ClientCertificateType.rsa_sign }, null, clientCAs);
}
}
This always results in a malformed packet.
I analyzed the problem using wireshark and tracked it down to
org.bouncycastle.asn1.DERSequence
out.write(BERTags.SEQUENCE | BERTags.CONSTRUCTED);
Somehow this is written to the stream where the length of the
subsequent DN is expected instead (at least by wireshark).
Am I doing something wrong or is this a bug maybe?
Thanks in advance for your help.
Regards,
Martin Körper