id-pda-dateOfBirth in Subject?
Hello, can someone please tell me the correct syntax and/or give me an example of using NID id-pda-dateOfBirth when requesting a certificate by calling openssl req -config openssl.cnf -new -key cert.key -subj /.../id-pda-dateOfBirth=? -out cert.csr must there be something special in the config file openssl.cnf when using this certificate for signing PDF files, I always get BER Encoding Error Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature
AES GCM + padding
Hi, I'm playing around with EVP_aes_128_gcm. This works, but it seems that EVP_* does not include padding. Is this expected/needed or did I miss a step? Thanks Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Obtaining a TLS session key
On Fri, Feb 8, 2013 at 12:11 AM, T J jordan.tre...@gmail.com wrote:
TLS keying material exporter, i.e., SSL_export_keying_material(), will
make your life much easier if you are just looking for a mechanism to
derive suitable keys for other uses assuming you are using recent
enough OpenSSL. That tls_openssl.c file I mentioned above has an
example of this, too.
Thanks very much Jouni - I think that will work nicely! Now if only there
was some documentation on it...
I happened to had implemented the ugly way before and reviewed the RFC
describing this functionality, so never had to try to find
documentation.. RFC 5705 describes the mechanism it high level. I'm
not sure whether the OpenSSL implementation is documented somewhere.
So to get a key, I would just establish the TLS connection, then use:
if (!SSL_export_keying_material(mySsl, key, key_len, label, label_len, NULL,
0, 0))
{
//handle error
}
before closing the connection?
After having completed TLS handshake and before closing the connection, yes.
Do that on both ends and I have my symmetric
keys for use in my app(s).
(My app uses a completely seperate radio path for bulk data encrypted using
specialised hardware - hence my requirement for a key.)
That's pretty much what I'm using this for, too, with EAP, i.e., only
authenticate and derive the key with TLS. SSL_export_keying_material()
works fine for that as long as you do not need to meet some protocol
design where key derivation is defined in a way that does not match
the functionality defined in RFC 5705.
- Jouni
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
build CSR with x500UniqueIdentifier
I need to build an CSR with x500UniqueIdentifier as subject like this | openssl req -noout -text -in csr.pem| |Certificate Request: Data: Version: 0 (0x0) Subject: x500UniqueIdentifier=karsten.reimers Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:bc:b5:a8:c3:9f:62:1d:68:ba:74:dc:7f:48:c4: d6:2b:52:88:23:53:6e:96:80:97:55:01:d3:b9:d5: ... 75:c1:fc:be:cd:45:11:73:41:b1:8c:a1:c4:d9:d0: dd:a8:4c:e7:b2:2c:9d:bf:d3:93:8e:e8:cd:60:d9: 8e:eb Exponent: 65537 (0x10001) ...| The /X500UniqueIdentifier/-Attribute has to be a Bitstring (RFC 2256). My request looks like: openssl req -new -batch -sha256 -key private.key -subj /x500UniqueIdentifier=karsten.reimers. -out csr.pem I believe it's the wrong way to transfer the UID with the '-subj' argument, because this way it causes the Attribute to be written as utf8string openssl asn1parse -in csr.pem -inform PEM 0:d=0 hl=4 l= 607 cons: SEQUENCE 4:d=1 hl=4 l= 327 cons: SEQUENCE 8:d=2 hl=2 l= 1 prim: INTEGER :00 11:d=2 hl=2 l= 26 cons: SEQUENCE 13:d=3 hl=2 l= 24 cons: SET 15:d=4 hl=2 l= 22 cons: SEQUENCE 17:d=5 hl=2 l= 3 prim: OBJECT :x500UniqueIdentifier 22:d=5 hl=2 l= 15 prim: UTF8STRING :karsten.reimers 39:d=2 hl=4 l= 290 cons: SEQUENCE 43:d=3 hl=2 l= 13 cons: SEQUENCE 45:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 56:d=4 hl=2 l= 0 prim: NULL 58:d=3 hl=4 l= 271 prim: BIT STRING 333:d=2 hl=2 l= 0 cons: cont [ 0 ] 335:d=1 hl=2 l= 13 cons: SEQUENCE 337:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption 348:d=2 hl=2 l= 0 prim: NULL 350:d=1 hl=4 l= 257 prim: BIT STRING So, can you tell me the right way ? thanks Karsten Reimers
Re: AES GCM + padding
It is a feature of GCM that the ciphertext (excluding the authentication tag) is identical length to the plaintext. Therefore no padding is required. Matt On 8 February 2013 14:27, Dirk Menstermann noadsple...@web.de wrote: Hi, I'm playing around with EVP_aes_128_gcm. This works, but it seems that EVP_* does not include padding. Is this expected/needed or did I miss a step? Thanks Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
Dear All, I am working on an embedded product which has the OpenSSL 0.9.8w library and acts as a client. It is communicating with another product which has the OpenSSL 0.9.8e library and acts as a server. A customer has supplied the client certificate for the server and the associated root CA that signed the client certificate. The client certificate is installed on the server, the root CA is installed on the client, and the client is authenticating the server. Unfortunately, the client is failing the authentication with the error 20 cant find local issuer certificate. Having spent sometime investigating why this is, I found the server certificate has the issuer in the form C=... ST=... L=... O=... OU=... CN=... and the root CA has the identical string for both issuer and subject in the reverse order CN=... OU=... O=... L=... St.. C... As a result X509_Name_cmp fails the comparison. I thought the ordering of the distinguished name in X509 is unimportant, yet it appears to be in OpenSSL. Is this true? I have trawled the web and found the following statement... According to X.500, both forms should be acceptable and a order-insensitive way to compare DN is defined. Unfortunately, looking up in their keystore for trusted certificates, many libraries compare issuer DN in the same order they are encoded. This problem affects especially OpenSSL-based software, which computes hash on DN to speed up certificate search. My reason for seeking assistance is to have the facts so that I can present them to the customer and suggest any restrictions that may be appropriate to the creation of the certificates. Thank you for your assistance and I look forward to your response. Thanks.. John John Simner BSc(Hons) MSc CEng. MIET Software Engineer Siemens Enterprise Communications Limited Tel: + 44 (0) 1908 817378 Please Note New Telephone number from 11/09/10: + 44 (0) 1908 817378 Email: john.sim...@siemens-enterprise.com www.siemens.co.uk/enterprisehttp://www.siemens.co.uk/enterprise Communication for the open mindedblocked::blocked::http://www.siemens.co.uk/open Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Ltd is a Trademark Licensee of Siemens AG. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this email. P Please consider the environment - do you really need to print this email?
Re: AES GCM + padding
Thank you Matt! On 08.02.2013 16:33, Matt Caswell wrote: It is a feature of GCM that the ciphertext (excluding the authentication tag) is identical length to the plaintext. Therefore no padding is required. Matt On 8 February 2013 14:27, Dirk Menstermann noadsple...@web.de mailto:noadsple...@web.de wrote: Hi, I'm playing around with EVP_aes_128_gcm. This works, but it seems that EVP_* does not include padding. Is this expected/needed or did I miss a step? Thanks Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
I think either you mis-read the web page, or the author is confused.
Looking at RFC 2253, it quotes X.501 which says:
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
Note that a DN is defined as a SEQUENCE OF not a SET OF. This means that in a
DN the order is important. Within an RDN, which is defined as SET OF, the
order is not important. Unfortunately, given the standard output formats for
DN, it is hard to tell if you are seeing one RDN or multiple. In order to
know, you have to look at the schema for the directory, if you can find it. :(
Or hope that people read and follow the RFC very carefully (such as the
examples in section 5).
Shor t answer: order counts.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
Since you need authoritative elements, start by downloading and reading
authoritative documents (all are freely available from ITU-T website).
X.509, section 7:
-
[...]
The issuer and subject fields of each certificate are used, in part, to
identify a valid path. For each pair of adjacent certificates in a valid
certification path, the value of the subject field in one certificate
shall match the value of the issuer field in the subsequent certificate.
In addition, the value of the issuer field in the first certificate
shall match the DN of the trust anchor. Only the names in these fields
are used when checking validity of a certification path.
Names in certificate extensions are not used for this purpose. A
certification path logically forms an unbroken chain of trusted points
in the Directory Information Tree between two users wishing to
authenticate. The precise method employed by users A and B to obtain
certification paths A?B and B?A may vary. One way to facilitate this is
to arrange a hierarchy of CAs, which may or may not coincide with all or
part of the DIT hierarchy. The benefit of this is that users who have
CAs in the hierarchy may establish a certification path between them
using the Directory without any prior information. In order to allow for
this each CA may store one certificate and one reverse certificate
designated as corresponding to its superior CA. The
distinguishedNameMatch matching rule, defined in 13.5.2 of ITU-T Rec.
X.501 | ISO/IEC 9594-2, should be used to compare the Distinguished Name
(DN) in the issuer field of one certificate with the DN in the subject
field of another.
[...]
-
The last sentence is the most important for your answer.
Then follow X.501, section 13.5.2 (with annotations from me):
-
[...]
distinguishedNameMatch MATCHING-RULE ::= {
SYNTAX DistinguishedName
ID id-mr-distinguishedNameMatch }
A presented distinguished name value matches a target distinguished name
value if and only if all of the following are true:
a) the number of RDNs in each is the same;
b) corresponding RDNs have the same number of AttributeTypeAndValue;
[EA: first RDNs are compared together, then second RDNs, etc]
c) corresponding AttributeTypeAndValue (i.e., those in corresponding
RDNs and with identical attribute types) have attribute values which
match as described in 9.4. [EA: order in AVAs isn't important, only
their value once normalized is]
[...]
-
You can further download and read X.520 for exact name comparison rules
(to be able to compare each name element, read the normalization
process, etc).
In case it's not clear, subject and issuer are sequences of RDNs
(RelativeDistinguishedName), and an RDN is a set of AVA
(AttributeTypeAndValue).
If you have a name that is represented as C=DE, O=Siemens, CN=John
Simner, then you have 3 RDNs, and each one has only 1 AVA. C=DE is
the AVA of the first RDN (C is the type, DE is the value).
When an RDN is composed of several AVAs, AVAs are generally separated by
'+' character (instead of ','). For example, C=DE, O=Siemens,
GN=John+SN=Simner, which is equal to C=DE, O=Siemens, SN=Simner+GN=John.
This string representation is only informative.
--
Erwann ABALEA
Le 08/02/2013 16:42, Simner, John a écrit :
Dear All,
I am working on an embedded product which has the OpenSSL 0.9.8w
library and acts as a client.
It is communicating with another product which has the OpenSSL 0.9.8e
library and acts as a server.
A customer has supplied the client certificate for the server and the
associated root CA that signed the client certificate.
The client certificate is installed on the server, the root CA is
installed on the client, and the client is authenticating the server.
Unfortunately, the client is failing the authentication with the error
20 cant find local issuer certificate.
Having spent sometime investigating why this is, I found the server
certificate has the issuer in the form C=... ST=... L=... O=... OU=...
CN=...
and the root CA has the identical string for both issuer and
subject in the reverse order CN=... OU=... O=... L=... St.. C...
As a result X509_Name_cmp fails the comparison.
I thought the ordering of the distinguished name in X509 is
unimportant, yet it appears to be in OpenSSL.
Is this true?
I have trawled the web and found the following statement...
According to X.500, both forms should be acceptable and a
order-insensitive way to compare DN is defined. Unfortunately, looking
up in their keystore for trusted certificates, many libraries compare
issuer DN in the same order they are encoded. This problem affects
especially OpenSSL-based software, which computes hash on DN to speed
up certificate search.
My reason for seeking assistance is to have the facts so that I can
present them to the customer and suggest any restrictions that may be
appropriate to the creation of the certificates.
Thank you for your assistance and I look forward to your
Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?
Ording is important. unfortunately the default order shown in the textual form is not the same as for ldap tools. using openssl asn1parse shows the encoding, country code should come first. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Only in FIPS mode: Crash in X509_sign() with memory corruption
I'm hoping someone has some insight into what I'm doing wrong or if I've just
bumped up against a bug. I'm using Visual Studio 2008 on Windows 8 and am in
the process of running existing code with FIPS enabled. As expected a few
things don't work, but in this case, I'm a bit stumped. I've narrowed it down
to the reproducer test shown below at the bottom of this email. If in not FIPS
mode, it runs fine. If in FIPS mode, X509_sign() crashes. After the crash the
call stack looks like it is corrupted so I can't tell where in openssl or the
fips module things are falling apart.
The error in the crash indicates it is a memory read violation:
Unhandled exception at 0x77ace3be (ntdll.dll) in Test.OpenSSL.exe:
0xC005:
Access violation reading location 0x2ed31dc7.
The call stack indicates it is trying to free up memory:
ntdll.dll!@RtlpLowFragHeapFree@8() + 0x2c bytes
ntdll.dll!_RtlFreeHeap@12() + 0x7e bytes
kernel32.dll!_HeapFree@12() + 0x14 bytes
msvcr90.dll!_free() + 0xcd bytes
libeay32.dll!0fb024dd()
[Frames below may be incorrect and/or missing, no symbols loaded for
libeay32.dll]
libeay32.dll!0fbb45ec()
kernel32.dll!_HeapFree@12() + 0x14 bytes
Visual Studio also has a runtime memory checker which is available when run as
Start with Application Verifier in the Debug drop-down menu. When I do
this, the application verifier reports the following:
Heap violation detected
Memory access operation in the context of an allocated block: heap
overrun or heap underrun.
The call stack indicates that the failure is in libeay32.dll:
libeay32.dll!0fbc0316()
[Frames below may be incorrect and/or missing, no symbols loaded for
libeay32.dll]
libeay32.dll!0fbb357e()
libeay32.dll!0fbb1619()
libeay32.dll!0fb5eb3b()
libeay32.dll!0fb5f87e()
libeay32.dll!0fb63989()
libeay32.dll!0fb63a96()
libeay32.dll!0fb81bd1()
Test.OpenSSL.exe!TestCreateCertificate() Line 339 + 0x11 bytes C++
0041()
So by all indication, in FIPS mode, I'm bumping up against memory corruption
problems that is crashing my app. Any ideas?
Thanks in advance for taking the time to read and respond to my request,
Lester
Test case. Crashes on X509_sign() only if in FIPS mode:
int TestCreateCertificate()
{
//Enable FIPS
if (FIPS_mode_set(1) != 1)
return E_FAIL;
//Initialize some randomness
DWORD dw = GetCurrentProcessId();
RAND_add(dw, sizeof(dw), 0);
dw = GetCurrentThreadId();
RAND_add(dw, sizeof(dw), 0);
dw = GetTickCount();
RAND_add(dw, sizeof(dw), 0);
//Create an X509 Cert and sign it.
RSA *rsa = RSA_generate_key(2048, RSA_F4, 0, 0);
if (!rsa)
{
printf(Failed to generate the RSA key, certificate generation
failed);
return E_FAIL;
}
EVP_PKEY *pKey = EVP_PKEY_new();
if (!pKey)
{
printf(Failed to generated a new pkey, certificate generation
failed);
return E_FAIL;
}
if (!EVP_PKEY_set1_RSA(pKey, rsa))
{
printf(An error occured accessing the private key, certificate
generation failed);
return E_OUTOFMEMORY;
}
X509 *x509cert = X509_new();
if (!x509cert)
{
printf(Failed to allocate memory for the X509 certificate);
return E_FAIL;
}
if (!X509_set_pubkey(x509cert, pKey))
{
printf(Error setting the public key for the X509
certificate\n);
goto egress;
}
//Crash occurs here on the call to X509_sign() if in FIPS mode.
Disable FIPS mode and it works.
const EVP_MD *digest = EVP_sha1();
if (!X509_sign(x509cert, pKey, digest))
{
printf(Error signing the X509 certificate\n);
goto egress;
}
egress:
if (NULL != x509cert)
{
X509_free(x509cert);
}
if (NULL != pKey)
{
EVP_PKEY_free(pKey);
}
//Turn off FIPS mode
FIPS_mode_set(0);
return 0;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
