command line hmac with key in hex
Hi,
I tried to use openssl command to generate an HMAC with a key
contains '\0', but failed.
openssl dgst -sha1 -hmac `cat key-file` input-file
I'm happy if dgst command supports binary format like enc command.
So I appended -hmachex key in hex option as the followings:
openssl dgst -sha1 -hmachex aabbcc0011223344 input-file
How about this patch?
Yours,
Shigeo
--- openssl-1.0.1c/apps/dgst.c.org 2012-02-11 01:46:19.0 +0900
+++ openssl-1.0.1c/apps/dgst.c 2012-08-02 14:47:31.368244214 +0900
@@ -74,6 +74,8 @@
#undef PROG
#define PROG dgst_main
+int set_hex(char *in,unsigned char *out,int size); // defined in apps/enc.c
+
int do_fp(BIO *out, unsigned char *buf, BIO *bp, int sep, int binout,
EVP_PKEY *key, unsigned char *sigin, int siglen,
const char *sig_name, const char *md_name,
@@ -126,6 +128,8 @@
char *engine=NULL;
#endif
char *hmac_key=NULL;
+ char hmac_key_data[EVP_MAX_KEY_LENGTH];
+ int hmac_key_len = -1;
char *mac_name=NULL;
int non_fips_allow = 0;
STACK_OF(OPENSSL_STRING) *sigopts = NULL, *macopts = NULL;
@@ -226,6 +230,15 @@
break;
hmac_key=*++argv;
}
+ else if (!strcmp(*argv,-hmachex))
+ {
+ if (--argc 1)
+ break;
+ hmac_key_len = strlen(*++argv) / 2;
+ if (!set_hex(*argv, hmac_key_data, sizeof
hmac_key_data))
+ break;
+ hmac_key = hmac_key_data;
+ }
else if (!strcmp(*argv,-mac))
{
if (--argc 1)
@@ -281,6 +294,7 @@
BIO_printf(bio_err,-signature file signature to verify\n);
BIO_printf(bio_err,-sigopt nm:vsignature parameter\n);
BIO_printf(bio_err,-hmac key create hashed MAC with
key\n);
+ BIO_printf(bio_err,-hmachex hexkey create hashed MAC with key
in hex\n);
BIO_printf(bio_err,-mac algorithm create MAC (not
neccessarily HMAC)\n);
BIO_printf(bio_err,-macopt nm:vMAC algorithm parameters or
key\n);
#ifndef OPENSSL_NO_ENGINE
@@ -410,7 +424,7 @@
if (hmac_key)
{
sigkey = EVP_PKEY_new_mac_key(EVP_PKEY_HMAC, e,
- (unsigned char *)hmac_key, -1);
+ (unsigned char *)hmac_key,
hmac_key_len);
if (!sigkey)
goto end;
}
dgst.patch
Description: Binary data
TLS server/client with self-signed certificate
Hell,I've got a question regarding self-signed X509v3 certificates used in a TLS1.0 server/client environment. A communication partner uses a self-signed certificate as attached to this mail (can be retrieved from the TLS server87.236.105.37:6619). My TLS client uses the following options: SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath) SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_callback); SSL_CTX_set_verify_depth(ctx, 9); SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TICKET );The server certificate is trusted in a directory where trusted certificates reside.In my application, a connect try ends with the following error:certificate verify error 20: unable to get local issuer certificate: depth=0, subject: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DE, issuer: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DEMy opinion is that the self-signed certificate has the X509v3 basic constraint CA flag set to "false": (openssl x509 -in John_Deere_OFTP2_Prod_3.cer -noout -text) X509v3 Basic Constraints: criticalCA:FALSEA connect via "openssl s_client" also fails with this message:openssl s_client -connect 87.236.105.37:6619 -tls1 -msg -debug -verify 9 -CApath /tmp/rootcerts/SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 501A2574C23B04543CC2CEAE6B930BB34B9A7A7A752213E32469399F77690FC8 Session-ID-ctx: Master-Key: 72CE5564EC8B591BE7E7B9156610379E73177615F26FCDEE0B58D81AB3C301DED5B0B4AF7881489E9E4D4D654554B72C Key-Arg : None Start Time: 1343890805 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate)---Is my assumption correct that the "CA"-flag must be set to "true" in order to work as a self-signed server certificate? I don't want to change my verify_callback function just in order to get it work (which could be easy). Conformity should be the first goal.Regards,Harald John_Deere_OFTP2_Prod_3.cer Description: application/x509-ca-cert
How to find correct issuer certificate in multi-level hierarchy?
Hi,
Is there a way in which I can determine the correct issuer certificate of
an issued certificate(either intermediate CA or end entity) based on
comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the End
entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons alone(As
this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension at
all)
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
Is something like this already available in openSSL?
One more question:
Given a certificate and trust store, openSSL's verify utility currently
returns OK in case the verification was successful. Is there a way in which
I can retrieve the formed and verified chain of certificates back?
--
Ashok
Re: How to find correct issuer certificate in multi-level hierarchy?
On 8/2/2012 10:04 AM, Ashok C wrote:
Hi,
Is there a way in which I can determine the correct issuer certificate
of an issued certificate(either intermediate CA or end entity) based
on comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the
End entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons
alone(As this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension
at all)
Those two are the standard ways though (specifically, doing both if
Authority Key Identifier is present).
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
In other words you are looking for a function to verify a certificate
given exactly one possible issuer.
Is something like this already available in openSSL?
I guess it at least exists as an internal function called from the
verify code, so look at the source code for that and see if you find a
call to a function that does what you want.
Alternatively, you could set up a certificate collection object in
memory containing only the suspected issuer certificate and then pass
that as the trusted certificate collection to the certificate verify
function.
One more question:
Given a certificate and trust store, openSSL's verify utility
currently returns OK in case the verification was successful. Is there
a way in which I can retrieve the formed and verified chain of
certificates back?
I sure hope so, as it is very useful on the client side to decide which
certificates to provide to the other end.
--
Ashok
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
call:+4531131610
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: How to find correct issuer certificate in multi-level hierarchy?
On Thu, Aug 02, 2012, Ashok C wrote:
Hi,
Is there a way in which I can determine the correct issuer certificate of
an issued certificate(either intermediate CA or end entity) based on
comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the End
entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons alone(As
this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension at
all)
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
Is something like this already available in openSSL?
You can use the function X509_verify to do this but you have to extract the
public key from the issuer using X509_get_pubkey.
One more question:
Given a certificate and trust store, openSSL's verify utility currently
returns OK in case the verification was successful. Is there a way in which
I can retrieve the formed and verified chain of certificates back?
There isn't a command line option to do this but the API call
X509_STORE_CTX_get1_chain will retrieve the chain from an X509_STORE_CTX
structure.
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: command line hmac with key in hex
On Thu, Aug 02, 2012, MITSUNARI Shigeo wrote: Hi, I tried to use openssl command to generate an HMAC with a key contains '\0', but failed. openssl dgst -sha1 -hmac `cat key-file` input-file I'm happy if dgst command supports binary format like enc command. So I appended -hmachex key in hex option as the followings: openssl dgst -sha1 -hmachex aabbcc0011223344 input-file How about this patch? You can achieve this using the generalised MAC interface to HMAC like this: openssl dgst -sha1 -mac HMAC -macopt hexkey:aabbcc 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: command line hmac with key in hex
Hi, You can achieve this using the generalised MAC interface to HMAC like this: openssl dgst -sha1 -mac HMAC -macopt hexkey:aabbcc I'm ashamed of my mail. Thank you for your advice. Yours, Shigeo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA testing with s_client/s_server
From: owner-openssl-us...@openssl.org On Behalf Of Erik Tkal Sent: Wednesday, 01 August, 2012 16:33 I'm playing around to see if I can observe client and server under various conditions when negotiating TLS 1.2 with newer certs. I created a root and server cert as ecdsa-with-SHA256. openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key eserver1.key -debug openssl s_client -CAfile eroot1.pem -debug Aside: s_server doesn't need CAfile if you don't do client-auth. However, the server issues a handshake alert and says no shared cipher. I see the client is sending a large set of suites but apparently none that the server wants. How do I do this properly? snip Only thing I can see that would fail silently is if your key doesn't use a named curve. In general OpenSSL server will skip ECC suites if the (certified) key is in a format not offered by the client in SupportedFormats, but s_client (at least) offers all defined formats; or using a curve not offered by the client in SupportedCurves, and s_client offers all named curves but not ad-hoc ones. Also it will skip EECDH suites if your temp ECDH key uses a curve not offered by the client, but s_server always does temp named curves (NIST/X962 P256 by default). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: TLS server/client with self-signed certificate
From: owner-openssl-us...@openssl.org On Behalf Of Harald Latzko Sent: Thursday, 02 August, 2012 03:03 snip self-signed certificate as attached to this mail (can be retrieved from the TLS server 87.236.105.37:6619). My TLS client uses the following options: SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath) snip Aside: it's a good thing you gave the server, because Outlook (which we use) blocks *.cer. I wish it didn't, but it does. The server certificate is trusted in a directory where trusted certificates reside. In my application, a connect try ends with the following error: Is the server cert in the directory named by tls_root_certpath *with a hashlink (or hashname)*? For the correct major version of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8) certificate verify error 20: unable to get local issuer certificate: snip My opinion is that the self-signed certificate has the X509v3 basic constraint CA flag set to false: snip A connect via openssl s_client also fails with snip: verify error 21 You show only the last part (resulting SSL-Session). I got as the first thing (except DN trimmed for posting): CONNECTED(0003) depth=0 emailAddress = deiningermichae...@johndeere.com, ... verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 emailAddress = deiningermichae...@johndeere.com, ... verify error:num=21:unable to verify the first certificate verify return:1 Note that you get error=20 first, and only after s_client overrides (which your app presumably doesn't) then you get error=21. Error=20 means it didn't find the cert in the truststore. As above, check it is in the directory with the correct hash. Errors in cert attributes (like BC) give other error codes. Is my assumption correct that the CA-flag must be set to true in order to work as a self-signed server certificate? I don't want to change my verify_callback function just in order to get it work (which could be easy). Conformity should be the first goal. No. CA:true, and (usually) KeyUsage:certSign, are required IF a cert (often, but not necessarily, selfsigned) is used to issue *other* (child) certs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to find correct issuer certificate in multi-level hierarchy?
Thank you Jacob and Stephen.
That brings one more question which was posted by Klaus sometime back:
Hi!
I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google and
validate its certificate:
openssl s_client -connect www.google.com:443 -CAfile dump.crt
When using openssl0.9.8k or openssl0.9.8x everything works as expected.
When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails
with:
Verify return code: 10 (certificate has expired)
CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan 7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for Verisign
with identical subject, whereas one is expired, the other not.
X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
searches if there is another valid one whereas openssl 1.0.0 stop with the
first expired certificate.
Is the new behavior the intended behavior? Is it possible to have the old
behavior also in new opensslversions?
Thanks
Klaus
Is this behaviour intended in openssl-1.0.0 ?
--
Ashok
On Fri, Aug 3, 2012 at 3:28 AM, Dr. Stephen Henson st...@openssl.orgwrote:
On Thu, Aug 02, 2012, Ashok C wrote:
Hi,
Is there a way in which I can determine the correct issuer certificate of
an issued certificate(either intermediate CA or end entity) based on
comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the
End
entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons alone(As
this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension at
all)
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
Is something like this already available in openSSL?
You can use the function X509_verify to do this but you have to extract the
public key from the issuer using X509_get_pubkey.
One more question:
Given a certificate and trust store, openSSL's verify utility currently
returns OK in case the verification was successful. Is there a way in
which
I can retrieve the formed and verified chain of certificates back?
There isn't a command line option to do this but the API call
X509_STORE_CTX_get1_chain will retrieve the chain from an X509_STORE_CTX
structure.
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
