Re: Force ASN.1 encoding routines to keep existing encoding

OK, I guess this is the only way to go then. Thanks for the help! Regards, Martin 2010/11/9 David Schwartz : > On 11/6/2010 7:44 AM, Martin Boßlet wrote: > >> I just tested, whether the BER-encoding is preserved if I do not alter >> any of the contents. Unfortunately, it seems as if the encoding

Re: Config file being ignored

Ok I am getting closer. I can get the engine to load now with this (better) config file openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/local/lib/engines/engine_pkcs11.so M

Re: Config file being ignored

Here is an example of what happens if I run it from the command line interface: openssl OpenSSL> engine dynamic -pre SO_PATH:/usr/local/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib64/opensc-pkcs11.so (dynamic) Dynamic engine loading support

Config file being ignored

Hi, I have the following in my /etc/ssl/openssl.cnf file: openssl_conf= openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 SO_PATH = /usr/local/lib/engines/engine_pkcs11.so MODULE_PATH = /usr/lib64/opens

Re: EC domain params instead of the OID in the pkcs8 key file?

On Tue, Nov 09, 2010 at 09:34:42PM +0100, Stef Hoeben wrote: > Hi, > > using the openssl tool, we generated an Elliptic Curve key pair > and put it into a pkcs8 file: > >0 48: SEQUENCE { >32: INTEGER 0 >6 48: SEQUENCE { >86: OBJECT IDENTIFIER ecPublicKey (1 2

EC domain params instead of the OID in the pkcs8 key file?

Hi, using the openssl tool, we generated an Elliptic Curve key pair and put it into a pkcs8 file: 0 48: SEQUENCE { 32: INTEGER 0 6 48: SEQUENCE { 86: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 176: OBJECT IDENTIFIER '1 2 840 10045 3 1 7' :

.deb packages for 1.0.0?

Has anyone seen .deb packages for openssl 1.0.0? I took a quick stab at converting the 0.9.8 debian files, but I ran into a lot of problems and it takes a long time to debug. -- Chris Bare ch...@bareflix.com __ OpenSSL Project

Re: Option -issuer_hash vs signature validation with -CAfile?

On 2010-11-09, Dr. Stephen Henson wrote: > On Tue, Nov 09, 2010, Jens Lechtenboerger wrote: > >> Hi there, >> >> I received an SMIME certificate and want to know the correct >> filename to use in the command "openssl smime -verify -CAfile >> ..." >> > > The hash based filename doesn't apply to t

Re: Upgrading the key size in OpenSSL certificate

On Tue, Nov 09, 2010 at 01:31:40PM -0500, josh kirbey wrote: > Thanks Viktor for your quick response. Even I am contesting the unnecessary > usage of 3072 bit sized key. > > Surprisingly, in the given scenario, if I write this line of code before > modifying the certificate it works like a charm.

Re: Upgrading the key size in OpenSSL certificate

Thanks Viktor for your quick response. Even I am contesting the unnecessary usage of 3072 bit sized key. Surprisingly, in the given scenario, if I write this line of code before modifying the certificate it works like a charm. pkcs7 = PKCS7_dup(pkcs7); Below is the flow of APIs 1) pkcs7 = PKCS7_d

Re: Upgrading the key size in OpenSSL certificate

On Tue, Nov 09, 2010 at 11:42:14AM -0500, josh kirbey wrote: > Hi All, > > We are required to upgrade the sizes of private/public key pairs to 3072 > bits from 1024 bits. Welcome to bureaucratic insanity. There is no rational basis for this requirement. Even 2048 bits is excessively conservative

Re: Option -issuer_hash vs signature validation with -CAfile?

On Tue, Nov 09, 2010, Jens Lechtenboerger wrote: > Hi there, > > I received an SMIME certificate and want to know the correct > filename to use in the command "openssl smime -verify -CAfile > ..." > The hash based filename doesn't apply to the -CAfile option: you can name the file anything you

.RSA conversion

Dear All, I have a certificate with a .rsa extension. On googling I found that this is a pkcs7 format using MD5 with RSA. Now my question is, is there a way to convert it to openssl specifics and handle?? I want to read it in say PEM.. thanks

Upgrading the key size in OpenSSL certificate

Hi All, We are required to upgrade the sizes of private/public key pairs to 3072 bits from 1024 bits. We have two main data structures, X509Stack and PKCS7. We fill these two structures at the initialization by reading the PEM files on disk. During the upgrade process, I pick the X509stack and pi

Option -issuer_hash vs signature validation with -CAfile?

Hi there, I received an SMIME certificate and want to know the correct filename to use in the command "openssl smime -verify -CAfile ..." In my particular example, openssl x509 -in smime.pem -issuer_hash -noout results in 9ec3a561. However, if I use that certificate (available as /etc/ssl/certs

Re: openssl verify fails

Michael Ströder writes: > Bruce Stephens wrote: [...] >> Ah, my fault. Obvious in retrospect: Debian's openssl finds the root >> cert because it's in the ca-certificates package! > > Did you use -CAfile as in my original posting when testing? I did. > Doesn't -CAfile set exclusively all trus

Re: openssl verify fails

On Tue, Nov 09, 2010 at 01:45:15PM +, Bruce Stephens wrote: > Michael Str??der writes: > > > Bruce Stephens wrote: > > [...] > > >> Ah, my fault. Obvious in retrospect: Debian's openssl finds the root > >> cert because it's in the ca-certificates package! > > > > Did you use -CAfile as in

Re: openssl verify fails

Bruce Stephens wrote: > Bruce Stephens writes: > >> "Dr. Stephen Henson" writes: >> >> [...] >> >>> Is that unmodified OpenSSL 0.9.8o? If so that's peculiar I get the expected >>> error here. >> >> No, it's Debian's 0.9.8o-2. > > Ah, my fault. Obvious in retrospect: Debian's openssl finds the

DESCryptoServiceProvider encryption and OpenSSL decrypt

Hello everyone. I'm using .NET to encrypt a file using DES. I'm using this: DESCryptoServiceProvider, CryptoTransform and CryptoStream Anyone knows how to use OpenSSL to decrypt the file? Thanks in advance. Best Regards.