Verify CSR fails for 256 byte modulus, what am I doing wrong?
I use the smart card to generate the private-public key pair on the card, get
the public key modulus from the card, generate a CSR for a user, compute the
MD5 Hash using SHA1, give this hash to the card for signing the hash with the
private key, append this signature to the CSR, and verify this CSR using
org.bouncycastle.jce.PKCS10CertificationRequest.
Below is my program which has the code for CSR generation and verification. I
have hardcoded the public modulus (String modulusStr) and the corresponding
signature (
String signedCSR) received from the card for the CSR generated using the
public key modulus. The values used are for 256 modulus, and the verification
fails.
You also see a commented set of values for the same variables, for 128 byte
modulus. Verification succeeds for 128 byte modulus. Can someone explain why
this is happening?
thanks,
Kannan
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.math.BigInteger;
import java.security.Key;
import java.security.KeyFactory;
import java.security.PublicKey;
import java.security.Security;
import java.security.Signature;
import java.security.spec.RSAPublicKeySpec;
import javax.security.auth.x500.X500Principal;
import org.bouncycastle.asn1.ASN1EncodableVector;
import org.bouncycastle.asn1.ASN1InputStream;
import org.bouncycastle.asn1.ASN1Sequence;
import org.bouncycastle.asn1.DERSet;
import org.bouncycastle.asn1.pkcs.CertificationRequestInfo;
import org.bouncycastle.asn1.x509.SubjectPublicKeyInfo;
import org.bouncycastle.asn1.x509.X509Name;
import org.bouncycastle.jce.PKCS10CertificationRequest;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.util.encoders.Base64;
import sun.security.pkcs.PKCS10Attributes;
import sun.security.util.DerOutputStream;
import sun.security.util.DerValue;
import sun.security.x509.X500Name;
import sun.security.x509.X500Signer;
public class GenerateCSR {
private static SubjectPublicKeyInfo getPublicKeyInfo(Key publicKey) throws
IOException {
ByteArrayInputStream bIn = new ByteArrayInputStream(publicKey.getEncoded());
ASN1InputStream dIn = new ASN1InputStream(bIn);
return new SubjectPublicKeyInfo((ASN1Sequence) dIn.readObject());
}
/**
* @param args
* @throws Exception
*/
public static void main(String[] args) throws Exception {
//128 byte modulus
// String modulusStr =
"AB198AC3A10AF5A7B7546F719D5FEB67797BC5A03CD0AFEAF2A8F370719F6E992BB7FBAF6F55E7D44610B6CBC962172A9AFF36859426E9B17A5BDD3A87A7583E153A6F6838ED4BC0BB268F2A5A51388A42B02417C17BBFF2D95C20C8C208A13FA043B46A4762C9927692232B405857570418D98AE7EB442D4697D3A9CA53BE81";
//256 byte modulus
String modulusStr =
"95E1ABBFFCA1AAB6CEAEF05EC534A87A8FBF3315619FDDF2C83D20FCBA7FBB06C077439D82DC62BB383309684672EC19CEDB594EAA5F2347C1FE3BEF52CAC9CA76018D5BF2D5569796E7493B02B29A7434DBEA18725CBF70C8814FD99528706F936EB9177AF21E6736E4B30A2156AFF39B77B4CCF9696A564D6977CA2DBCA8881CDDE03369EA41F04DC37F79F5AE1D9890F4596053158E35FD4CCE5C00EA55EAE8182D3DE081AF473A8A8EDD211B1BF0206891CE674623177BCEDED39698915B08B77CC475413301DAF97058B620B3E866167C67672697028B864B1B5C11F195143A5241E022CB4797C918B24EFDEFF8D4576A789EBC78A40A1D25FF2EDF6CE1";
byte[] modulus = HexString.hexToBuffer(modulusStr);
String sigAlg = "SHA1WithRSA";
String userDN = "cn=ob2,o=arcot";
RSAPublicKeySpec publicKeySpec = new RSAPublicKeySpec(new
BigInteger(1,modulus), new BigInteger("65537"));
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PublicKey publicKey = keyFactory.generatePublic(publicKeySpec);
SubjectPublicKeyInfo ski = getPublicKeyInfo(publicKey);
ASN1EncodableVector v = new ASN1EncodableVector();
CertificationRequestInfo reqInfo = new CertificationRequestInfo(new
X509Name(userDN), ski, new DERSet(v));
// Build an instance of pkcs10 with the public key from the card.
sun.security.pkcs.PKCS10 pkcs10 = new sun.security.pkcs.PKCS10(publicKey);
DerOutputStream out, scratch;
byte [] certificateRequestInfo;
Signature signature = null;
// signature is not initialized because CSR is not going to be signed here; if
not on the card.
signature = Signature.getInstance(sigAlg);
// Build the info.
X500Principal x500 = new X500Principal(userDN);
X500Name x500name = new X500Name(x500.getEncoded());
X500Signer requester = new X500Signer(signature, x500name);
X500Name subject = requester.getSigner();
// Encode CSR info, wrap in a sequence for being signed.
scratch = new DerOutputStream();
// PKCS #10 v1.0.
scratch.putInteger(BigInteger.ZERO);
// X.500 name.
subject.encode(scratch);
// Public key.
Key subjectPublicKeyInfo = pkcs10.getSubjectPublicKeyInfo();
scratch.write(subjectPublicKeyInfo.getEncoded());
PKCS10Attributes attributeSet = new PKCS10Attributes();
attributeSet.encode(scratch);
out = new DerOutputStream();
// Wrap it.
out.write(DerValue.tag_Sequence, scratch);
certificateRequestInfo = out.toByteArray();
scratch = out;
requester.getAlgorithmId().encode(scratch);
//CSR hash signed with the private key of the smart card.
Re: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
On Wed, Dec 15, 2010 at 11:14:59AM -0500, Jeff Saremi wrote: > So under situations that are not entirely clear, a call to > SSL_get_peer_certificate() returns null after a successful SSL accept is > done on the server. > > My question is if there are conditions under which one cannot rely on > the presence of the peer certificate even if SSL_VERIFY_PEER is set? If the client signed the handshake with a private key and presented the corresponding certificate chain, then on an initial handshake you'll see the client cert and the full trust chain and your verification callback will be invoked. If the client resumes a previously established session, your verification callback will not be called, rather only the leaf certificate will be saved in the resumed session, and its verification status will be cached. Under these conditions, whether the session is resumed or not, SSL_get_peer_certificate() should return the leaf client certificate. Have never run into any surprised with missing client certs. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
> From: owner-openssl-us...@openssl.org On Behalf Of Jeff Saremi > Sent: Wednesday, 15 December, 2010 11:15 > We have some intermittent problems which seem to go away after > restarting our server. > The problem is that the client's certificate disappears on the server, > even though SSL_VERIFY_PEER is set in the context using > SSL_CTX_set_verify(). > Is the SSL_CTX* always set before you create (any) SSL* from it? (Or (re)set in the SSL* before you handshake?) Could you have a bug in (any!) other code that clobbers memory? (These are often very hard to debug, at least in C and C++ . Maybe you can put in monitoring/debug code that checks every H hours or C connections or M messages or somesuch that settings are still correct.) > So under situations that are not entirely clear, a call to > SSL_get_peer_certificate() returns null after a successful > SSL accept is > done on the server. > > My question is if there are conditions under which one cannot rely on > the presence of the peer certificate even if SSL_VERIFY_PEER is set? > *On server* just SSL_VERIFY_PEER only causes it to *allow* client auth, by sending CertReq and processing the response(s). accept still succeeds if the client chooses not to auth. Add SSL_VERIFY_FAIL_IF_NO_PEER_CERT to make accept fail. But I see no reason that should be changed by server restart, if you have the same clients attempting the same connections. (Maybe you don't; maybe clients differ from one week to the next, or at different times of day or seasons of the year or something. Or maybe you have one or a few bad client(s) who only connect every 2 weeks, so it usually happens to be more than a week since the last server (re)start. Etcetera Yul Brynner.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl version constants - question and request
On Tue, Dec 14, 2010 at 09:52:58AM -0500, Kenneth Goldman wrote:
> Question:
>
> OPENSSL_VERSION_TEXT is undocumented. Can I count on it being there and
> up to date, or is it for internal use only?
>
> Request:
>
> OPENSSL_VERSION_NUMBER varies between a long and an int constant, Could
> it please be standardized?
It is standardized, but the standard has changed as OpenSSL evolved, it
is quite stable now. Postfix parses the number explained as follows:
/*
* OPENSSL_VERSION_NUMBER(3):
*
* OPENSSL_VERSION_NUMBER is a numeric release version identifier:
*
* MMNNFFPPS: major minor fix patch status
*
* The status nibble has one of the values 0 for development, 1 to e for
* betas 1 to 14, and f for release. Parsed OpenSSL version number. for
* example
*
* 0x000906000 == 0.9.6 dev 0x000906023 == 0.9.6b beta 3 0x00090605f ==
* 0.9.6e release
*
* Versions prior to 0.9.3 have identifiers < 0x0930. Versions between
* 0.9.3 and 0.9.5 had a version identifier with this interpretation:
*
* MMNNFFRBB major minor fix final beta/patch
*
* for example
*
* 0x000904100 == 0.9.4 release 0x000905000 == 0.9.5 dev
*
* Version 0.9.5a had an interim interpretation that is like the current
* one, except the patch level got the highest bit set, to keep continu-
* ity. The number was therefore 0x0090581f.
*/
The parser is:
long version = OPENSSL_VERSION_NUMBER; /* SSLeay() for run-time version */
if (version < 0x0930) {
info->status = 0;
info->patch = version & 0x0f;
version >>= 4;
info->micro = version & 0x0f;
version >>= 4;
info->minor = version & 0x0f;
version >>= 4;
info->major = version & 0x0f;
} else if (version < 0x00905800L) {
info->patch = version & 0xff;
version >>= 8;
info->status = version & 0xf;
version >>= 4;
info->micro = version & 0xff;
version >>= 8;
info->minor = version & 0xff;
version >>= 8;
info->major = version & 0xff;
} else {
info->status = version & 0xf;
version >>= 4;
info->patch = version & 0xff;
version >>= 8;
info->micro = version & 0xff;
version >>= 8;
info->minor = version & 0xff;
version >>= 8;
info->major = version & 0xff;
if (version < 0x00906000L)
info->patch &= ~0x80;
}
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
We have some intermittent problems which seem to go away after restarting our server. The problem is that the client's certificate disappears on the server, even though SSL_VERIFY_PEER is set in the context using SSL_CTX_set_verify(). So under situations that are not entirely clear, a call to SSL_get_peer_certificate() returns null after a successful SSL accept is done on the server. My question is if there are conditions under which one cannot rely on the presence of the peer certificate even if SSL_VERIFY_PEER is set? thanks Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
state_machine.c using 2 bio_s_mem's
Hello all In demos/state_machine/state_machine.c two bio_s_mem's are used as read and write bio's under SSL. What are the major differences between two bio_s_mem's versus one bio pair (2 bio_s_bio's)? Why would i prefer one over the other? Best Wishes Alon
openssl version constants - question and request
Question: OPENSSL_VERSION_TEXT is undocumented. Can I count on it being there and up to date, or is it for internal use only? Request: OPENSSL_VERSION_NUMBER varies between a long and an int constant, Could it please be standardized?
state_machine.c using 2 bio_s_mem's
Hello all In demos/state_machine/state_machine.c two bio_s_mem's are used as read and write bio's under SSL. What are major differences between two bio_s_mem's versus one bio pair (2 bio_s_bio's)? Why would i prefer one over the other? Best Wishes Alon
Having errors while compiling the openssl code (openssl-1.0.0b release)
I am usingLinux debian 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux and I am trying to compile openssl-1.0.0b release. I did as step I - ./Configure Then as step II I did make and got the following errors as linking errors Can anyone help me... ../libcrypto.a(cmll-x86.o): In function `Camellia_encrypt': cmll-586.s:(.text+0xa0): multiple definition of `Camellia_encrypt' ../libcrypto.a(cmll_misc.o):cmll_misc.c:(.text+0x30): first defined here ../libcrypto.a(cmll-x86.o): In function `Camellia_decrypt': cmll-586.s:(.text+0x4d0): multiple definition of `Camellia_decrypt' ../libcrypto.a(cmll_misc.o):cmll_misc.c:(.text+0x0): first defined here ../libcrypto.a(cmll-x86.o): In function `Camellia_set_key': cmll-586.s:(.text+0x11d0): multiple definition of `Camellia_set_key' ../libcrypto.a(cmll_misc.o):cmll_misc.c:(.text+0x60): first defined here ../libcrypto.a(cmll-x86.o): In function `Camellia_cbc_encrypt': cmll-586.s:(.text+0x2280): multiple definition of `Camellia_cbc_encrypt' ../libcrypto.a(cmll_cbc.o):cmll_cbc.c:(.text+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [link_app.] Error 1 make[2]: Leaving directory `/root/openssl-1.0.0b/apps' make[1]: *** [openssl] Error 2 make[1]: Leaving directory `/root/openssl-1.0.0b/apps' make: *** [build_apps] Error 1
state_machine.c using 2 bio_s_mem's
Hello all In demos/state_machine/state_machine.c two bio_s_mem's are used as read and write bio's under SSL. What are the major differences between two bio_s_mem's versus one bio pair (2 bio_s_bio's)? Why would i prefer one over the other? Best Wishes Alon
Re: How to disable compression?
Try this SSL_CTX * tls_ctx; STACK_OF(SSL_COMP)* compression ; compression = SSL_COMP_get_compression_methods(); sk_SSL_COMP_zero(compression); It should disable the compression support for !! You can also use below API accordingly to enable/disable required encryption/authentication algorithms for a given context. SSL_CTX_set_cipher_list(*tls_ctx, "!RSA:!ADH:!NULL:!aNULL!RC4:!RC5:!kEDH:!DES:!AES256-SHA:!EXPORT") Best Regards , Ram Corin Lawson wrote: Hi All, Is it possible to establish an SSL connection with no compression? How? While I'm at it, is it possible to use no encryption? I.e. I only want SSL to authenticate/verify identity (handshake). Cheers, Corin. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to disable compression?
Ramaswamy BM wrote: Try this SSL_CTX * tls_ctx; STACK_OF(SSL_COMP)* compression ; compression = SSL_COMP_get_compression_methods(); sk_SSL_COMP_zero(compression); It should disable the compression support for !! You can also use below API accordingly to enable/disable required encryption/authentication algorithms for a given context. SSL_CTX_set_cipher_list(*tls_ctx, "!RSA:!ADH:!NULL:!aNULL!RC4:!RC5:!kEDH:!DES:!AES256-SHA:!EXPORT") Best Regards , Ram Corin Lawson wrote: Hi All, Is it possible to establish an SSL connection with no compression? How? While I'm at it, is it possible to use no encryption? I.e. I only want SSL to authenticate/verify identity (handshake). Cheers, Corin. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL over Windows named pipes
Hello, I would like to use SSL over Windows named pipes. Is there any sample code which does about the same thing? Thanks. -zoltan. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
