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.
Re: openssl verify fails
Bruce Stephens wrote: Bruce Stephens bruce.steph...@isode.com writes: Dr. Stephen Henson st...@openssl.org 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 root cert because it's in the ca-certificates package! Did you use -CAfile as in my original posting when testing? Doesn't -CAfile set exclusively all trusted CA certs? So the pre-installed CA certs should not be used as trust anchors in this case. Frankly this cert verification stuff seems really odd to me and the exact behaviour seems to be largely unknown. Ciao, Michael. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
On Tue, Nov 09, 2010 at 01:45:15PM +, Bruce Stephens wrote: Michael Str??der mich...@stroeder.com 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 trusted CA certs? Apparently not, the normal openssl.cnf is read and (on Debian, if ca-certificates is installed) that gives a set of extra CA certificates. Correct. This *augments* the default certificate list, found in the 'certs/' sub-directory and 'cert.pem' file of the directory reported by openssl version -d. From crypto/cryptlib.h: #define X509_CERT_AREA OPENSSLDIR #define X509_CERT_DIR OPENSSLDIR /certs #define X509_CERT_FILE OPENSSLDIR /cert.pem The OpenSSL toolkit does not include any default roots. These are configured by the O/S release engineering teams. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
Michael Ströder mich...@stroeder.com 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 trusted CA certs? Apparently not, the normal openssl.cnf is read and (on Debian, if ca-certificates is installed) that gives a set of extra CA certificates. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 filename... 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/9ec3a561.0 on my system) then verification fails. What is issuer_hash good for? Running strace on openssl smime -verify with the preinstalled list of certificates shows that /etc/ssl/certs/75680d2e.0 is the CAfile necessary for validation. What is the recommended way to find the hash value 75680d2e? Thanks in advance Jens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 pick the certificate and generate the new keys with 3072 bits size. Also, I am successfully able to set the public key for this cert using the API X509_set_pubkey. Using the new public key in the Cert and the new private key, we prepare a certificate request that is to be sent to the CA server. Along with the new certificate request, we also send the Cert chain (PKCS value) to the provisioning server for verification. PKCS value is not really touched here. On the provisioning end, when we call X509_verify_cert it always fails with the error, Certificate Verification error : 7. this stands for X509_V_ERR_CERT_SIGNATURE_FAILURE Is there anything I am doing wrong in this flow? Or can anybody comment on the approach I am using for the key size upgrade. Please let me know. Thanks, Josh
.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
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 filename... The hash based filename doesn't apply to the -CAfile option: you can name the file anything you want. It does apply to -CApath 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/9ec3a561.0 on my system) then verification fails. What is issuer_hash good for? Running strace on openssl smime -verify with the preinstalled list of certificates shows that /etc/ssl/certs/75680d2e.0 is the CAfile necessary for validation. What is the recommended way to find the hash value 75680d2e? Note the hash algorithm changed from OpenSSL 0.9.8 and 1.0.0 so be careful you aren't using different versions for the hash calculation and the verification. The usual reason for a different hash is that it isn't the correct issuer certificate. If you do: openssl x509 -in smime.pem -issuer -noout it should match: openssl x509 -in ca.pem -subject -noout Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 for most applications, you're likely much better off with 1280 or 1536-bit keys. During the upgrade process, I pick the X509stack and pick the certificate and generate the new keys with 3072 bits size. Also, I am successfully able to set the public key for this cert using the API X509_set_pubkey. Using the new public key in the Cert and the new private key, we prepare a certificate request that is to be sent to the CA server. Along with the new certificate request, we also send the Cert chain (PKCS value) to the provisioning server for verification. PKCS value is not really touched here. On the provisioning end, when we call X509_verify_cert it always fails with the error, Certificate Verification error : 7. this stands for X509_V_ERR_CERT_SIGNATURE_FAILURE If you modify a certificate, its signature will be invalid. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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_dup(pkcs7); (I simply duplicate the value back to same pointer) 2) Generate key pair (new keys) 3) X509_set_pubkey 4) PEM_write_bio_PKCS7 (Create cert chain from PKCS value) The duplication is even done before any certificate key change. I fail to understand, why is that so. Thanks, Josh On Tue, Nov 9, 2010 at 12:02 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: 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 for most applications, you're likely much better off with 1280 or 1536-bit keys. During the upgrade process, I pick the X509stack and pick the certificate and generate the new keys with 3072 bits size. Also, I am successfully able to set the public key for this cert using the API X509_set_pubkey. Using the new public key in the Cert and the new private key, we prepare a certificate request that is to be sent to the CA server. Along with the new certificate request, we also send the Cert chain (PKCS value) to the provisioning server for verification. PKCS value is not really touched here. On the provisioning end, when we call X509_verify_cert it always fails with the error, Certificate Verification error : 7. this stands for X509_V_ERR_CERT_SIGNATURE_FAILURE If you modify a certificate, its signature will be invalid. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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. Yes, but the signature of a modified X509 object is still invalid... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 filename... The hash based filename doesn't apply to the -CAfile option: you can name the file anything you want. It does apply to -CApath Thank you for your quick reply, my fault. I meant to use that option. The problem below remains, however. 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/9ec3a561.0 on my system) then verification fails. What is issuer_hash good for? Running strace on openssl smime -verify with the preinstalled list of certificates shows that /etc/ssl/certs/75680d2e.0 is the CAfile necessary for validation. What is the recommended way to find the hash value 75680d2e? Note the hash algorithm changed from OpenSSL 0.9.8 and 1.0.0 so be careful you aren't using different versions for the hash calculation and the verification. I retried on the command line with: OpenSSL 0.9.8k 25 Mar 2009 The usual reason for a different hash is that it isn't the correct issuer certificate. If you do: openssl x509 -in smime.pem -issuer -noout I find: issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Client Authentication and Email it should match: openssl x509 -in ca.pem -subject -noout I get: openssl x509 -in 75680d2e.0 -subject -noout subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services which does not match. (Besides, -subject_hash results in 75680d2e.) However: openssl x509 -in 9ec3a561.0 -subject -noout subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Client Authentication and Email (-subject_hash results in 9ec3a561.) Surprisingly, verification succeeds if I put 75680d2e.0 into a separate directory for CApath (although the issuer does not match the subject), it fails with a directory containing only 9ec3a561.0 (where issuer and subject match). Again, with /etc/ssl/certs as CApath, openssl figures out that it needs 75680d2e.0. How? (The displayed issuer does not appear to play any role in that process.) Thanks Jens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
.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 http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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'
: }
274: OCTET STRING, encapsulates {
...
However, instead of the 2nd object identifier (that tells which
EC it is), we'd need the domain parameters of the EC themselves.
It this possible with the openssl tool -- or with openssl itself?
Thanks!
Stef
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
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 840 10045 2 1)
176: OBJECT IDENTIFIER '1 2 840 10045 3 1 7'
: }
274: OCTET STRING, encapsulates {
...
However, instead of the 2nd object identifier (that tells which
EC it is), we'd need the domain parameters of the EC themselves.
It this possible with the openssl tool -- or with openssl itself?
Have you looked at the ecparam(1) manpage?
...
-param_enc arg
This specifies how the elliptic curve parameters are encoded.
Possible value are: named_curve, i.e. the ec parameters are speci-
fied by a OID, or explicit where the ec parameters are explicitly
given (see RFC 3279 for the definition of the EC parameters struc-
tures). The default value is named_curve. Note the implicitlyCA
alternative ,as specified in RFC 3279, is currently not imple-
mented in OpenSSL.
Example (1.0.0a):
$ openssl ecparam -genkey -name prime256v1 -text -param_enc explicit
Field Type: prime-field
Prime:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:ff
A:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:fc
B:
5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86:
bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2:
60:4b
Generator (uncompressed):
04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4:
40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8:
98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a:
7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40:
68:37:bf:51:f5
Order:
00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:
ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:
63:25:51
Cofactor: 1 (0x1)
Seed:
c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26:
b7:81:9f:7e:90
-BEGIN EC PARAMETERS-
MIH3AgEBMCwGByqGSM49AQECIQD/AQAAAP//
/zBbBCD/AQAAAP///AQgWsY12Ko6
k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+
kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK
fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/AP//vOb6racXnoTz
ucrC/GMlUQIBAQ==
-END EC PARAMETERS-
-BEGIN EC PRIVATE KEY-
MIIBaAIBAQQgHqdKw3PmrxxFzUr4JFjFetuHhG2kT/nnkFyqVBFKSn2ggfowgfcC
AQEwLAYHKoZIzj0BAQIhAP8B
MFsEIP8B///8BCBaxjXYqjqT57Pr
vVV2mIa8ZR0GsMxTsPY7zjw+J9JgSwMVAMSdNgiG5wSTamZ44ROdJreBn36QBEEE
axfR8uEsQkf4vOblY6RA8ncDfYEt6zOg9KE5RdiYwpZP40Li/hp/m47n60p8D54W
K84zV2sxXs7LtkBoN79R9QIhAP8A//+85vqtpxeehPO5ysL8
YyVRAgEBoUQDQgAEXPmUSlKlJY/uhPRoOeeTloBgJsB3hlcHCNPU03tlMeoESWeM
MG4FoMedrrlTtt+oSJZ8uLt96gSZEUM380rXrg==
-END EC PRIVATE KEY-
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
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/opensc-pkcs11.so init = 0 [req] distinguished_name = req_distinguished_name [req_distinguished_name] Yet when I try to load openssl it insists on loading /usr/lib64/engines/libpkcs11.so instead of the files that I have specified. If I don't have this in my config file and just specify the engine in the openssl command line interface then it works fine. Any idea what could be going on? Why would it seem to ignore my config. -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 [Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib64/opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL engine (dynamic) Dynamic engine loading support (pkcs11) pkcs11 engine But if I try it with the given config file: openssl OpenSSL engine Error configuring OpenSSL 139855973107368:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(/usr/local/ssl/lib64/engines/libpkcs11.so): /usr/local/ssl/lib64/engines/libpkcs11.so: cannot open shared object file: No such file or directory 139855973107368:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 139855973107368:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 139855973107368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=pkcs11 139855973107368:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine configuration error:eng_cnf.c:204:section=pkcs11_section, name=SO_PATH, value=/usr/local/lib/engines/engine_pkcs11.so 139855973107368:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:235:module=engines, value=engine_section, retcode=-1 error in engine On 11/09/2010 04:57 PM, Bram Cymet wrote: 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/opensc-pkcs11.so init = 0 [req] distinguished_name = req_distinguished_name [req_distinguished_name] Yet when I try to load openssl it insists on loading /usr/lib64/engines/libpkcs11.so instead of the files that I have specified. If I don't have this in my config file and just specify the engine in the openssl command line interface then it works fine. Any idea what could be going on? Why would it seem to ignore my config. -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 MODULE_PATH = /usr/lib64/opensc-pkcs11.so init = 0 but when I got to use the engine I get: openssl (lock_dbg_cb): already locked (mode=9, type=30) at eng_list.c:284 Auto configuration failed 23985:error:26078067:engine routines:ENGINE_LIST_ADD:conflicting engine id:eng_list.c:116: 23985:error:2606906E:engine routines:ENGINE_add:internal list error:eng_list.c:288: 23985:error:260B6067:engine routines:DYNAMIC_LOAD:conflicting engine id:eng_dyn.c:540: 23985:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:235:module=engines, value=engine_section, retcode=-1 any idea why that would be happening? On 11/09/2010 05:28 PM, Bram Cymet wrote: 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 [Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib64/opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL engine (dynamic) Dynamic engine loading support (pkcs11) pkcs11 engine But if I try it with the given config file: openssl OpenSSL engine Error configuring OpenSSL 139855973107368:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(/usr/local/ssl/lib64/engines/libpkcs11.so): /usr/local/ssl/lib64/engines/libpkcs11.so: cannot open shared object file: No such file or directory 139855973107368:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 139855973107368:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 139855973107368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=pkcs11 139855973107368:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine configuration error:eng_cnf.c:204:section=pkcs11_section, name=SO_PATH, value=/usr/local/lib/engines/engine_pkcs11.so 139855973107368:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:235:module=engines, value=engine_section, retcode=-1 error in engine On 11/09/2010 04:57 PM, Bram Cymet wrote: 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/opensc-pkcs11.so init = 0 [req] distinguished_name = req_distinguished_name [req_distinguished_name] Yet when I try to load openssl it insists on loading /usr/lib64/engines/libpkcs11.so instead of the files that I have specified. If I don't have this in my config file and just specify the engine in the openssl command line interface then it works fine. Any idea what could be going on? Why would it seem to ignore my config. -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 dav...@webmaster.com: 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 is not preserved. I did the following: d2i_PKCS7_bio(file,p7); and then directly i2d_PKCS7_bio(file2, p7); again. file was BER-encoded using e.g. an Octet String in constructed form with inifinite length, which was DER-encoded in primitive form using definite length in the output. Is there a way how I can circumvent the reencoding? Best regards, Martin Really, the best solution is just not to do that then. If it wants the signature done on the byte-for-byte form supplied, then do the signature on the byte-for-byte form supplied. Don't convert it into any other form and then convert it back because absent DER, it's unreasonable to expect that to produce the same output. Keep both the PKCS7 object and a raw byte version. Compute and check signatures on the raw byte version. Do other checks on the PKCS7 object. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
