Secure Remote Password (SRP)

[Rohit Khera [C]]

I am trying to get information on versions and usage of the Secure Remote 
Password Protocol (SRP) APIs in OpenSSLv3.


  1.  Are SRPv3, v6, and/or v6a supported?



  1.  I found the following information in the OpenSSL documents on the 
following C API for SRP: SRP_create_verifier(), SRP_user_pwd_new(), 
SSL_CTX_set_srp_password()

While the following documents the API :

https://www.openssl.org/docs/man3.0/man3/SRP_VBASE_new.html

Are there any examples of client and server programs that use these interfaces 
in order to register and authenticate a user?



  1.  The docs state that the APIs are deprecated -  are new versions of the 
APIs planned or can we expect SRP functionality to be unavailable in future 
versions of OpenSSL?

/R

OpenSSL-3 ENGINESDIR development vs deployment

[Wrestler, C David CTR (USA)]

Background, earlier versions of my project were using OpenSSL 1.n.n, the output 
stayed within it's checkout directory, and the .DLLs deployed to where-ever the 
project was deployed.

Now trying to implement OpenSSL 3, after compiling it seems to be keep 
referring to the directories it was configured with.   -prefix   --openssldir
I can see the OPENSSLDIR, ENGINESDIR, MODULESDIR via openssl version -a   The 
man pages reference Environment variables, but those don't seem to have any 
effect, and the ENGINES related docs all say deprecated for PROVIDERS.


How do I set the openSSL 3, (openssl.exe, libssl-3.dll, and libcrypto-3.dll, 
openssl.cnf, etc)  to use the eventual installed location(s)?
reasons why I need to be able:
1.  The users will not be running from a directory structure like my 
development directories.

2.  Compiling to Program Files (x86) requires Administrator (or something)  
privileges which I don't have.

3.  Also compiling on our BuildServer, the build job will not have access to 
drive C:


Thanks,
cdw

Need Help to check DH_generate_key() functionality

[Priyanka C via openssl-users]

Dear OpenSSL Team,

While migrating to OpenSSL 3.0 we are facing issue with use of 
DH_generate_key(). Getting dh->pub_key NULL.
Logic used is as given below, I have omitted the error handling code.


  *   p and g buffer is of type unsigned char *
  *   p_len is 128 and g_len is 1.

  DH *dh;
dh = DH_new();
dh->params.p = BN_bin2bn(p, p_len, NULL);
dh->params.g = BN_bin2bn(g, g_len, NULL);
DH_generate_key(dh);

I have checked openssl man pages 
(https://www.openssl.org/docs/manmaster/man3/DH_generate_key.html).
According to which DH_generate_key() expects dh to contain the shared 
parameters p and g only, still not able to generate pub_key.

Tried solutions given on following links:
Approach 1:
https://github.com/openssl/openssl/issues/11108
  Used DH_new_by_nid() instead of DH_new() .

Approach 2:
We were skeptical about the values of p and g so tried setting valid values for 
p q and g using DH_set0_pqg().

BIGNUM *a = BN_bin2bn(p, p_len, NULL);
BIGNUM *b = BN_bin2bn(g, g_len, NULL);
DH_set0_pqg(dh, a, NULL, b);

But this did not help, as this set function does not change q value if NULL is 
passed.
We don't have idea about what can be a valid value for q which we can set.

Approach 3:
Currently working on the solution given on this link, using EVP wrappers for DH 
key generation.
https://www.mail-archive.com/openssl-users@openssl.org/msg88906.html

Please help to look into this and guide with possible solutions.

Thanks,
Priyanka

Help needed with X509_STORE_CTX structure

[Srinivas, Saketh (c)]

HI,

i need to set the current_issuer field in an object of the X509_STORE_CTX 
structure. Can any suggest the setter function for this.

Also, current_crl_score and current_reasons also are needed to be 0 for me. Can 
you suggest setters for these variables.

Thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

need help with X509_STORE_CTX structure.

[Srinivas, Saketh (c)]

HI,

i need to set the current_issuer field in an object of the X509_STORE_CTX 
structure. Can any suggest the setter function for this.  current_crl_score and 
current_reasons also are needed to be 0 for me. Can you suggest setters for 
these variables.

Thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

X509_STORE_CTX object doubt

[Srinivas, Saketh (c)]

Hi,

for X509_STORE_CTX object we have a function X509_STORE_CTX_set_cert to set the 
cert pointer  (x509* cert)
is there any get function for this variable.

X509_STORE_CTX_get_current_cert is not for cert. Because, there is another 
variable current_cert.

thanks,
Saketh.


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

bignum to evp key

[Srinivas, Saketh (c)]

HI,

i have EvpKeyPair from GenerateEvpKeyPair(dh_p, dh_g, )

How can I get the public key and priv key from keypair. The below function 
gives them as bignums but not Evp_pkey.

(EVP_PKEY_get_bn_param(pEvpKeyPair, OSSL_PKEY_PARAM_PUB_KEY, )

I want pub key and priv keys as evp_pkey.

Thanks,
Saketh.


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

error with cipher EVP_des_ede3_cbc in openssl 3.0

[Srinivas, Saketh (c)]

Hi

I am trying to encrypt and decrypt using EVP_des_ede3_cbc() type.  iam using 
openssl3.0

the functions i am using are

encryption side:

EVP_EncryptInit_ex ->  EVP_EncryptUpdate ->  EVP_EncryptFinal_ex

decryption side:
--
EVP_DecryptInit_ex ->  EVP_DecryptUpdate -> EVP_DecryptFinal_ex

but its failing in the EVP_DecryptFinal_ex.

Does any have any idea on this. it's works for cipher EVP_aes_128_cbc().

Thanks,
Saketh.



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: [EXTERNAL] Re: need some help with the block size value

[Srinivas, Saketh (c)]

i am using openssl 3.0

From: openssl-users  on behalf of Matt 
Caswell 
Sent: Tuesday, February 15, 2022 6:45 PM
To: openssl-users@openssl.org 
Subject: [EXTERNAL] Re: need some help with the block size value



On 15/02/2022 12:13, Srinivas, Saketh (c) wrote:
> Hi,
>
> i am trying to get the block size of EVP_des_ede3_cbc cipher using the
> below function but it's not returning anything.
>
> EVP_CIPHER_get_block_size(EVP_des_ede3_cbc())


This code looks fine to me, and I just tested this and it returned the
expected result of 8.

When you say "it's not returning anything" do you mean it returns 0 or
something else? What version of OpenSSL are you using?

Matt


>
> Does anyone have any idea how to.
>
> thanks,
> Saketh.
>
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. and its Affiliates that is
> confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or distribution by others or
> forwarding without express permission is strictly prohibited. If you are
> not the intended recipient, please notify the sender immediately and
> then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

need some help with the block size value

[Srinivas, Saketh (c)]

Hi,

i am trying to get the block size of EVP_des_ede3_cbc cipher using the below 
function but it's not returning anything.

EVP_CIPHER_get_block_size(EVP_des_ede3_cbc())

Does anyone have any idea how to.

thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

does Openssl 3.0 has backward compatiblity.

[Srinivas, Saketh (c)]

Does openssl 3.0 supports the openssl 1.0 pkcs12 files. Is it backward 
compatible. For me it giving error in PKCS12_parse function.


thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

error with p12 file importing

[Srinivas, Saketh (c)]

HI,

I am getting this error while importing p12 file

PKCS12_parse failed, error : error:0308010C:digital envelope 
routines::unsupported

can anyone explain this?

thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Openssl 3.0 support

[Srinivas, Saketh (c)]

Hi,

Does openssl 3.0 still support TLSv 1.0 and TLSv1.1. or they are deprecated, 
because there were some deprecations like sha1 etc.

Thanks,
Saketh.



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Doubt regarding ssl options

[Srinivas, Saketh (c)]

Hi,

what is the difference between  SSL_CTX_set_min_proto_version and 
SSL_set_min_proto_version.
How will they effect the SSL handsahke.

I can see two versions numbers in the PCAP files,

  1.  content type is handshake , version v1.0
  2.  handshake type client hello, version v1.2

what is the difference and how to modify them.

Thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

need help with EVP_PKEY_derive function to generate shared key

[Srinivas, Saketh (c)]

Hi,
 i am trying to modify a function which earlier used openss1 to compute shared 
key the aruguments to the function are:

 rc_vchar_t *pub , rc_vchar_t *priv ;  '// public and private keys.

 if (eay_v2bn(>pub_key, pub) < 0)
goto end;
if (eay_v2bn(>priv_key, priv) < 0)
goto end;



 DH_compute_key(v, dh_pub, dh))


For openssl3 we are trying to use (EVP_PKEY_derive) the below code is how i 
implemented:

 rc_vchar_t *pub,  rc_vchar_t *priv,  // parameters to the function

 BIGNUM *dh_pub_key = NULL;
 BIGNUM *dh_priv_key = NULL;

if (eay_v2bn(_pub_key, pub) < 0)
 goto end;
if (eay_v2bn(_priv_key, priv) < 0)
 goto end;

 pub_key_buf = (unsigned char*) malloc( BN_num_bytes(dh_pub_key));

  if (!pub_key_buf)
goto end;
  BN_bn2nativepad(dh_pub_key, pub_key_buf, BN_num_bytes(dh_pub_key));

  priv_key_buf = (unsigned char*) malloc( BN_num_bytes(dh_priv_key));

   if (!priv_key_buf)
goto end;
  BN_bn2nativepad(dh_priv_key, priv_key_buf, BN_num_bytes(dh_priv_key));

  pklen = strlen((char*)priv_key_buf);
  peerklen = strlen((char*)pub_key_buf);

  const unsigned char *pub_key = ( const unsigned char *)pub_key_buf;
  const unsigned char *priv_key = ( const unsigned char *)priv_key_buf;

  pkey = d2i_PrivateKey(EVP_PKEY_RSA, , _key, pklen);

 peerkey = d2i_PublicKey(EVP_PKEY_RSA, , _key, peerklen);

ctx = EVP_PKEY_CTX_new(pkey, NULL);


The problem its failing at  Pkey and PeerKey creation.  Does anyone have any 
idea how to get it working. Also can anyone suggest how to know the correct 
replacemant for  EVP_PKEY_RSA, OR any way to know what is the type for my pub 
and priv keys


Thanks,
Saketh.


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Help with TLS call on openssl3

[Srinivas, Saketh (c)]

HI,

I am using Openssl3. while Run a TLS call, call connected successfully, but at 
the end of the call i got the error message:

SSL3 alert write:fatal:decode error
 SSL error (a000126): unexpected eof while reading
 ERROR on SSL_read err=1 flag=0
 Initiating SSL shutdown

I think some issue while disconnecting the session. When i tried with openssl1 
it did not throw the error. I am testing with sipp.

IN wireshark i can see sipp sending TCP-FIN-ACK and openssl3 responded with 
TCP-PSH-ACK.
Whereas in the openssl1 case it responded with a tcp message "encrypted alert" .

I think some issue with closing TLS connection in openssl3.

Can someone help me understand why?

thanks,
Saketh.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: Openssl and tls 1.2

[Somshekar C Kadam]

Thanks Viktor for clarification

Regards
Somshekar C Kadam
9036660538


On Wed, Aug 14, 2019 at 9:43 AM Viktor Dukhovni 
wrote:

> Java's TLS library is not OpenSSL.  This is not the right list
> for help with TLS in JDK8.  Speculatively, the timeout might be
> related to IPv6 being enabled on the board with JDK8 and Linux 4.x.
> Perhaps you're trying the IPv6 address, timing out, and then failing
> over to IPv4.  Or some middle-box is choking on larger client hellos.
> You'll need to analyze a packet capture.
>
> > On Aug 14, 2019, at 1:29 PM, Somshekar C Kadam 
> wrote:
> >
> > Hi ,
> > we are running java 1.6 (older build) and java 1.8(newer build) on the
> same arm target board with different builds.
> > On 1.6 java we have Linux Kernel 2.6.35 and with Java 1.8 Linux kernel
> 4.x. version. so 2 environments and 2 use cases newer and older build.
> > while we access https website link
> https://transparencyreport.google.com/https/overview?hl=en
> >
> > we see it takes less than 2 seconds using java 1.6. (older build)
> > we see it takes 10 seconds using java 1.8 (newer build)
> >
> > On Java 1.8 did try disabling GCM ciphers and trying still we get the
> same 10 seconds delay.
> >
> > Attaching log of tls handshake for both. Not sure its to do with tls,
> may be java is causing the delay.
> >
> > I am not sure, please provide any pointers or feedback to rootcause it
> that will help to understand why we get 10seconds delay.
> >
> > One more info if just use curl on on newer build setup, it works fine
> within 2 seconds to access the https link.
>
> Curl may well be using OpenSSL, but that's not where you're seeing
> a problem, so the help you'll get on this list is rather limited.
> Try wireshark or similar.
>
> --
> Viktor.
>
>

Openssl and tls 1.2

[Somshekar C Kadam]

Hi ,
we are running java 1.6 (older build) and java 1.8(newer build) on the same
arm target board with different builds.
On 1.6 java we have Linux Kernel 2.6.35 and with Java 1.8 Linux kernel 4.x.
version. so 2 environments and 2 use cases newer and older build.
while we access https website link
https://transparencyreport.google.com/https/overview?hl=en

we see it takes less than 2 seconds using java 1.6. (older build)
we see it takes 10 seconds using java 1.8 (newer build)

On Java 1.8 did try disabling GCM ciphers and trying still we get the same
10 seconds delay.

Attaching log of tls handshake for both. Not sure its to do with tls, may
be java is causing the delay.

I am not sure, please provide any pointers or feedback to rootcause it that
will help to understand why we get 10seconds delay.

One more info if just use curl on on newer build setup, it works fine
within 2 seconds to access the https link.

Regards
Somshekar C Kadam
9036660538


>
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1565589724 bytes = { 28, 22, 178, 239, 29, 7, 47, 174, 250, 
171, 197, 25, 93, 255, 194, 202, 106, 235, 247, 232, 181, 51, 10, 143, 1, 145, 
240, 220 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, 
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, 
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, 
SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, 
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, 
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, 
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
***
main, WRITE: TLSv1 Handshake, length = 81
main, WRITE: SSLv2 client hello message, length = 110
main, READ: TLSv1 Handshake, length = 81
*** ServerHello, TLSv1
RandomCookie:  GMT: 1565589726 bytes = { 95, 183, 13, 179, 158, 139, 220, 121, 
126, 177, 252, 92, 190, 70, 216, 42, 44, 211, 170, 12, 68, 79, 87, 78, 71, 82, 
68, 0 }
Session ID:  {218, 176, 53, 135, 9, 102, 98, 200, 249, 250, 100, 210, 61, 85, 
125, 213, 80, 185, 85, 50, 109, 140, 181, 243, 66, 73, 21, 167, 101, 144, 37, 
142}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 
***
%% Created:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
main, READ: TLSv1 Handshake, length = 3404
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=*.google.com, O=Google LLC, L=Mountain View, ST=California, C=US
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  modulus: 
245180144051627998005140595818075599955125194441556727090071225256086865995689796657805609058948597911700194626350813904546039062934052539036137622626636812327708917108199181528060004740262961328242367212112500989713592230373064908372586180039146323508049812949792276263041753718117997123682956328116433868099282108178109910867224855775469681943864772035897640898641778595308067540309939544912886565922473092234490442592589841706182290746974282686920486312604695195928067536451594810730756448614586986400482653133247203222853000557785259166528637871490302752850099518899633231236493795050081835001646811083199
  public exponent: 65537
  Validity: [From: Tue Jul 30 00:14:13 GMT+05:30 2019,
   To: Mon Oct 21 23:53:00 GMT+05:30 2019]
  Issuer: CN=Google Internet Authority G3, O=Google Trust Services, C=US
  SerialNumber: [1b0b4c01 0d429a9d 993930f3 79310ee0]

Certificate Extensions: 8
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 4D 8A E9 66 E7 F5 44 6E   4F 22 BA DC 57 7B 00 26  M..f..DnO"..W..&
0010: 21 FE 73 91!.s.
]
]

[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: 77 C2 B8 50 9A 67 76 76   B1 2D C2 86 D0 83 A0 7E  w..P.gvv.-..
0010: A6 7E BA 4B...K
]

]

[3]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
 [URIName: http://crl.pki.goog/GTSGIAG3.crl]
]]

[4]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: *.google.com
  DNSName: *.android.com
  DNSName: *.appengine.google.com
  DNSName: *.cloud.google.com
  DNSName: *.crowdsource.google.com
  DNSName: *.g.co
  DNSName: *.gcp.gvt2.com
  DNSName: *.gcpcdn.gvt1.com
  DNSName: *.ggpht.cn
  DNSName: *.google-analytics.com
  DNSName: *.google.ca
  DNSName: *.google.cl
  DNSName: *.google.co.in
  DNSName: *.

Re: [openssl-users] Decrypt old openssl files

[Bhasker C V]

Wow ! thanks

openssl -md md5 ...
does the trick. All my docs are back now.
That was a great help Double  thanks to Jeff.

On Sat, Feb 11, 2017 at 7:05 PM, Jeffrey Walton  wrote:

> >  I have two systems one with openssl 1.0.1e (debian wheezy) and the new
> one
> > with openssl 1.1.0c (debian stretch)
> >
> >  The files encrypted with 1.0.1e are not decryptable via 1.1.0c
> > These are the investigations I have done
> >
> > on my system with 1.0.1e openssl
> > $ echo some text > file
> > $ cat file  | openssl  aes-256-cbc  -pass pass:test  > file.enc
> > $ md5sum file.enc
> > 5482ea53a6677865d1e559ac3057738c  file.enc
> >
> > when I bring that file over to my system with 1.1.0c openssl
> > $ md5sum file.enc
> > 5482ea53a6677865d1e559ac3057738c  file.enc
> > $ cat file.enc | openssl  aes-256-cbc  -d -pass pass:test
> > bad decrypt
> > 4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:
> bad
> > decrypt:crypto/evp/evp_enc.c:529:
> >
> > Please can someone tell me what other options I Am supposed to pass to
> get
> > decryption done successfully.
>
> From the OpenSSL 1.1.0c-3 update notes. I don't believe its in the
> 'openssl enc' man page yet
> (https://www.openssl.org/docs/man1.0.1/apps/enc.html).
>
>   The openssl enc command changed the default digest (used to create the
> key
>   from passphrase) from MD5 to SHA256 since the version 1.1.0. The digest
> can
>   be specified with the -md option.
>
> Jeff
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Decrypt old openssl files

[Bhasker C V]

Hi,
 I have two systems one with openssl 1.0.1e (debian wheezy) and the new one
with openssl 1.1.0c (debian stretch)

 The files encrypted with 1.0.1e are not decryptable via 1.1.0c
These are the investigations I have done

on my system with 1.0.1e openssl
$ echo some text > file
$ cat file  | openssl  aes-256-cbc  -pass pass:test  > file.enc
$ md5sum file.enc
5482ea53a6677865d1e559ac3057738c  file.enc

when I bring that file over to my system with 1.1.0c openssl
$ md5sum file.enc
5482ea53a6677865d1e559ac3057738c  file.enc
$ cat file.enc | openssl  aes-256-cbc  -d -pass pass:test
bad decrypt
4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:crypto/evp/evp_enc.c:529:

Please can someone tell me what other options I Am supposed to pass to get
decryption done successfully.

Thanks in advance
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SSL_Write() returns error SSL_ERROR_SYSCALL with errno 11, and it wants caller to try again

[Camiel C. Coppelmans]

Hi,

I did encounter a situation which I think could be better handled by
openssl lib. In my system, when working under heavy load, sometimes while
calling SSL_Write, it will return SSL_ERROR_SYSCALL, which we treated as an
error and aborted the operation.  Next time, when we wanted to send a new
packet, passing a new buffer with a different length to the SSL_Write
function, it returns the error SSL_ERROR_SSL with the following details:

*140701061253440:error:1409F07F:SSL routines:ssl3_write_pending:bad write
retry:s3_pkt.c:1097*

Meaning that SSL_Write was actually expecting us to call it again with the
same buffer and length that was used when it returned SSL_ERROR_SYSCALL.

It turns out that when SSL_Write returned SSL_ERROR_SYSCALL, errno value
was set to 11 (EAGAIN or EWOULDBLOCK), so I figured out that, although
openssl didn't explicitly indicate us to try again, the underling socket
did, therefore I started to handle this specific scenario the same way I
would if SSL_Write would have returned SSL_ERROR_WANT_WRITE, and it worked.

My question is: Is it ok to trust the errno in this scenario? Can I handle
it that way I handled?

And two: If Openssl is expecting us to retry the SSL_Write call, it should
have returned SSL_ERROR_WANT_WRITE, like it does for all other scenarios.
So, maybe it is something to be improved for a future release.

This issue happened in the following versions: 0.9.8zb and 1.0.2e

Thanks,
Camiel
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Help installing OpenSSL 1.1.0 pre6 on Windows 2012 R2

[Harster, Kaarl C CIV NAVSEA KPWA, 104]

Hello,
 I've tried many times now to install OpenSSL 1.1.0 pre6 on my Windows 2012 R2 
64bit machine.
We are wanting to run 64bit everything.
I have installed 
ActivePerl 5.24.0.2400
Microsoft Visual Studio Ultimate 2012 version 11.0.50727.1 RTMREL with Visual 
C++2012 installed in it.

When I try to use OpenSSL 1.1.0 pre6 for some reason it can't find the nmake 
commend and it looks to me that the do_win54a and other files are missing in 
the ms folder.
Sorry but I'm new to ActivePerl. I think the nmake is a perl problem maybe. Is 
there additional step you have to do after installing Activeperl to get the 
nmake command to work?
I did find on the ActiveState site the following:
"For 64-bit Perl on 64-bit Windows currently the only supported compiler is the 
Visual C++ compiler included in the Windows Server 2003 SP1 Platform SDK (aka 
the April 2005 edition). 
Use the SetEnv.cmd script to set the PATH, LIB, and INCLUDE environment 
variables to the correct value for building ActivePerl extensions with this 
command:
"C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd" /XP64 /RETAIL"

I tried installing the SDK on my Windows 2012 R2 64bit machine and of course it 
will not install can't find files it needs.
Has anyone tried this? 

So I tried going back a version on openSSL
When I try to use the 1.0.2h version of openSSL, the nmake and the other do_ 
files are in the ms folder and seem to work  but I cannot seem to get past the 
following error message:
c:\openssl\openssl-1.0.2h>nmake -f ms\nt.mak
...
Assembling: tmp32\sha1-586.asm
tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands
tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\ml.EXE"' : return code '0x1'
Stop.

Or when I try the following I get a different error:

c:\openssl\openssl-1.0.2h>perl configure VC-WIN64A --prefix=C:\_openssl-1.0.2a_x
64_release_static
Configuring for VC-WIN64A
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-shared   [default]
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl2 [default]  OPENSSL_NO_SSL2 (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=1
CC=cl
CFLAG =-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYS
NAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_N
O_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DO
PENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVP
AES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
EX_LIBS   =
CPUID_OBJ =x86_64cpuid.o
BN_ASM=bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rs
az-x86_64.o rsaz-avx2.o
EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-s
ha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sh
a256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC  =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
ENGINES_OBJ   =
PROCESSOR =
RANLIB=true
ARFLAGS   =
PERL  =perl
SIXTY_FOUR_BIT mode
DES_INT used
RC4_CHUNK is unsigned long long

Configured for VC-WIN64A.

c:\openssl\openssl-1.0.2h>ms\do_win64a

c:\openssl\openssl-1.0.2h>perl util\mkfiles.pl  1>MINFO

c:\openssl\openssl-1.0.2h>cmd /c "nasm -f win64 -v"  1>NUL 2>&1

c:\openssl\openssl-1.0.2h>if 1 NEQ 0 goto ml64

c:\openssl\openssl-1.0.2h>perl ms\uplink-x86_64.pl masm  1>ms\uptable.asm

c:\openssl\openssl-1.0.2h>ml64 -c -Foms\uptable.obj ms\uptable.asm
Microsoft (R) Macro Assembler (x64) Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: ms\uptable.asm

c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl VC-WIN64A  1>ms\nt.mak

c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl

[openssl-users] 1.1.0-pre4: openssl speed chacha

[c^]

Hi there,

I don't seem to be able to benchmark chacha, nor does it appear in the list
when I test all.
Is this expected?

I can see it in 'openssl ciphers -V "ALL"' and also negotiate from a client.

Thanks
CraigT
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl-1.1.0 sha1 performance

[c^]

Afternoon,

I have been running some speed tests of openssl 1.0.1, 1.0.2 and 1.1.0
versions against various compiler optimisations. Special interest was given
to the more commonly used primitives, rsa's, aes's etc.

I noticed that SHA1's have some significant performance improvements.
However the multiplier by which it improved by diminishes as you approach
8k/16k block sizes.

Any ideas why this tails off?

I noticed no other 'statistically significant' change in other primitives,
although freely admit i have not exhaustively checked.

openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 16 size blocks:
9225205 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 64 size blocks:
7275849 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 256 size blocks:
4821329 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 1024 size blocks:
2059373 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 8192 size blocks:
327032 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16 size blocks:
23362218 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 64 size blocks:
14131714 sha1's in 2.99s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 256 size blocks:
7166139 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 1024 size blocks:
2413233 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 8192 size blocks:
335803 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16384 size blocks:
169210 sha1's in 3.00s

I assume the positive change was part of:
  *) Extensive assembler packs updates, most notably:

- x86[_64]: AES-NI, PCLMULQDQ, RDRAND support;
- x86[_64]: SSSE3 support (SHA1, vector-permutation AES);
- x86_64:   bit-sliced AES implementation;
- ARM:  NEON support, contemporary platforms optimizations;
- s390x:z196 support;
- *:GHASH and GF(2^m) multiplication implementations;

 [Andy Polyakov]

Has anyone else completed any similar tests?

Thank you,
CraigT
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[R C Delgado]

Thank you Steve,

This is very useful information.

>>I'm getting private queries about this (why is there is such reluctance
to discuss the delights of FIPS 140-2 in public?).

I've noticed technical questions related to private FIPS certifications
never get answered, at least not on this distribution list. I know mine was
never answered. Maybe that's why users are reluctant to post their
questions publicly and hope that a private email will get answered
for sure.
Obviously there are also company restrictions related to confidentiality to
consider, knowing that competitors and even customers are registered on the
distribution list too.

BTW, I had guessed why FIPS certification questions don't get answered:
it's all about funding, but thank you for explaining it in your email.
>>... FIPS validation business; it has gone
from economically marginal to unsustainable and as a result we'll
probably be shutting down the corporate entity that does the FIPS
validation work at the end of this year. I want to turn off the lights
while that business is still (barely) in the black...

I think a formal statement should be posted on the OpenSSL website, so that
all (FIPS) users know the level of support to expect.

Thank you all for you great work.


On Wed, Dec 2, 2015 at 6:56 PM, Steve Marquess  wrote:

> On 12/02/2015 11:16 AM, Steve Marquess wrote:
> > If you don't know or care what FIPS 140-2 is, be very glad this isn't >
> your problem and turn your charitable attentions to some worthy > cause. >
> > The CMVP has introduced a new policy that will result in the > effective
> termination of many extant validations if they are not > updated by January
> 31 2016[1]. That update is a pure paper shuffle > -- adding politically
> correct verbiage to the Security Policy > document -- but without it the
> CMVP will "de-list" the validation. > > ... > > So if you're a corporate
> user of the OpenSSL FIPS Object Module
> > v2.0 validation(s) #1747/#2398/#2473, and want to continue using
> > it past January 31, please be aware we'll need someone to cover
> > that $1250 cost. > > Don't send any money to us; if you're interested
> in covering this > cost I'll put you directly in touch with the test lab to
> work out > specific payment arrangements. > > ...
>
> I'm getting private queries about this (why is there is such reluctance to
> discuss the delights of FIPS 140-2 in public?). To save some time here's an
> anonymous query I received, with my reply:
>
> >> ... We are thinking of using openssl FIPS in our product but >> haven't
> started the work yet. >> >> What will be the impacts to people like us who
> want to use the >> OpenSSL FIPS modules but haven't started yet? Should we
> still use >> the modules now or should we wait? > > Well, the
> #1747/#2398/#2473 validation is very widely used, so > while the CMVP may
> block our future FIPS related initiatives I don't > think they would dare
> kill those validations outright. Some > stakeholder will pay the cost to
> surmount this latest obstacle, in > fact we have had some contacts already.
> > > So I think you have safety in numbers if you decide to use that >
> module now, and should be good for the next year or two. Keep
> > in mind though that the long term future of the FIPS module is in
> > doubt, as the upcoming OpenSSL 1.1 release may not have any FIPS
> > support (at least initially). We're not going to try tackling a sixth
> new
> > open source based validation on an at-risk basis like we've done in
> > the past, as we think that risk is now too high. A new validation will
> > require a sponsor willing to absorb that risk and champion the new >
> validation within the government bureaucracy, and we have no such > current
> prospects. > >> Will there be any code changes in the modules and will
> there be
> >> new version of module (or will it be just the policy document >>
> updated)? > > It's just a paper shuffle with no real-world impacts for end
> users.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Software Foundation
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marqu...@openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Hello,

With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.
How deep does the certificate chain have to be?
If I have 2 self-signed CA certificates, and a non-CA certificate is
received for verification, will this hit the problem?

Also, is it a condition of the bug that both CA certificates have to have
the same subject names and keys, as suggested in the file?

Many thanks for your help.
RCD
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Thank you very much. It really helps.

On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell m...@openssl.org wrote:



 On 10/07/15 13:09, R C Delgado wrote:
  Hello,
 
  With regards to CVE-2015-1793, I've seen the example in
 verify_extra_test.c.
  How deep does the certificate chain have to be?
  If I have 2 self-signed CA certificates, and a non-CA certificate is
  received for verification, will this hit the problem?
 
  Also, is it a condition of the bug that both CA certificates have to
  have the same subject names and keys, as suggested in the file?


 The conditions for triggering the bug are a little complicated, but I'll
 do my best to explain it.

 Under normal circumstances things work as follows:

 We are provided with a certificate to verify from a remote peer. Lets
 call the certificate we are trying to verify Leaf.
 As well as Leaf that has been provided from the remote peer, they also
 supply us with a set of untrusted certs.
 Finally we also have a store of trusted certs.

 OpenSSL will first attempt to build a certificate chain. The chain
 building works as follows (much simplified):

 1. Set Leaf as the top of the chain
 2. Look for the issuer of the cert at the top of the chain from within
 the untrusted set. If we find it add it to the top of the chain
 3. Repeat (2) until we can't find any more certs from the untrusted set
 4. Look for the issuer of the top of the chain from the set of trusted
 certs
 5. Repeat (4) until we can't find any more certs from the trusted set

 If we've found a valid chain with a trusted self signed cert at the top,
 then we stop there. If not, then we continue to look to see if there is
 an alternative chain that can be built. This works as follows:

 Pop all the trusted certs off the top of the chain, then start popping
 the untrusted certs off. Each time we pop an untrusted cert off start
 the chain building again from step 4.

 The bug occurs when during the initial chain building:
 1) We have added at least one cert from the untrusted set
 2) We have added at least one cert from the trusted store

 For 1.0.2 there is the additional condition:
 3) After doing (1) and (2) above we do not have a valid chain

 Finally (for both 1.0.1 and 1.0.2)
 4) After popping off at least one untrusted cert from the chain we can
 build an alternative valid chain

 Under the above conditions the end entity cert Leaf could issue a new
 certificate even though it is not supposed to (I'll call that invalid
 certificate Bad).

 So these certs would need to be present (at a minimum):

 Chain 1:

 Trusted Cert 1
 |
 Untrusted Cert 1
 |
 Leaf
 |
 Bad

 Chain 2:

 Trusted Cert 2
 |
 Leaf
 |
 Bad

 There are other possible longer chains, but this is the minimum set. For
 1.0.2, Chain 1 would have to be non-trusted, even though we have added a
 trusted cert. This can occur if Trusted Cert 1 is not self signed and
 its issuer is not in the trusted store. For 1.0.1 any chain will do.
 Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers
 of Leaf (i.e. they have the same subject names and public keys). Chain 2
 must be trusted (so Trusted Cert 2 has to be a self-signed root).

 Matt
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Hello,

One further question. Can you please confirm that the alternative
certificate chain feature is enabled by default? It seems to be implied in
all emails regarding this matter, and I'm assuming the Advisory email would
have mentioned it otherwise.

I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS
exists but is not set in the flags member by default when a new X509
context is initialised. And my code does not modify the context to include
this flag.

Please let me know if I'm missing something.

(I'm using OpenSSL 1.0.1o)

Many thanks,
RCD



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Problems converting to .p12 from Apache format

[Davidson, Brian C.]

I am trying to help a client convert his SSL certificate to a .p12 format so it 
can be installed in a Java keystore on a server running Apache.  Based on the 
various error messages I am getting, I think that the root certificate needs to 
be a part of the conversion command (sample shown below):


openssl pkcs12 -export -in mycert.crt -inkey mykey.key \
-out mycert.p12 -name tomcat -CAfile myCA.crt \
-caname root -chain


If I am right, I need to get a copy of the root certificate and put it in the 
proper directory for OpenSSL to access.  My problem is I am running Cygwin on a 
Windows machine and I have no idea where the root certificate should be stored. 
 I tried changing the directory in my script to be where the other pieces are 
located (via my Desktop) but OpenSSL didn't like the directory change.

I am very green on this process in particular, so any help would be greatly 
appreciated.  Thanks.
inline: image001.gif

Using openssl for AS2 [I]

[Dwipin C]

Classification: For internal use only

Hi,

I am using openssl - OpenSSL 0.9.8e 23 Feb 2007 on Solaris. I need to 
use this to decrypt and verify AS2 messages coming in from customers. Is 
this possible ? 

I do not see a cms option available.

When I use openssl smime -verify -CAfile ca-file -out output-file , 
the verification is successful but the output contains the Content-Type, 
Content-Transfer-Encoding and Content-Disposition Headers.

How do I get around this issue ?

Thanks and Regards,
Dwipin Chandran.

---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

Re: Using openssl for AS2 [I]

[Dwipin C]

Classification: For internal use only

Thanks Jakob.

Do you have any pointers around script that decodes the 
Content-Transfer-Encoding ? Is there something that is widely used ?

Thanks and Regards,
Dwipin Chandran.



From:
Jakob Bohm jb-open...@wisemo.com
To:
openssl-users@openssl.org, 
Date:
04/04/2013 11:02 PM
Subject:
Re: Using openssl for AS2  [I]



On 4/4/2013 9:00 AM, Dwipin C wrote:
 Classification: For internal use only

 Hi,

 I am using openssl - OpenSSL 0.9.8e 23 Feb 2007 on Solaris. I need to
 use this to decrypt and verify AS2 messages coming in from customers. Is
 this possible ?

OpenSSL 0.9.8e is an old insecure version, please upgrade to the latest
security upgrade, either version 0.9.8y (contains only security fixes),
1.0.0k (contains 1.0.0 features and security fixes) or 1.0.1e (contains
1.0.0 features, 1.0.1 features and security fixes).


 I do not see a cms option available.

The cms command is a version 1.0.0 and later feature, upgrade to 1.0.0k,
1.0.1e or use the smime command.


 When I use openssl smime -verify -CAfile ca-file -out output-file ,
 the verification is successful but the output contains the Content-Type,
 Content-Transfer-Encoding and Content-Disposition Headers.

 How do I get around this issue ?

Just filter the result through a simple script that removes those 
headers and decodes the Content-Transfer-Encoding.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
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




---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

Re: Certificate expiry alarms Reg.

[Ashok C]

Thanks a lot Jeff,
The book is really very useful.

On Sun, Feb 24, 2013 at 12:36 AM, Jeffrey Walton noloa...@gmail.com wrote:

 On Fri, Feb 15, 2013 at 9:25 AM, Ashok C ash@gmail.com wrote:
  On Thu, Feb 14, 2013 at 5:31 PM, Jeffrey Walton noloa...@gmail.com
 wrote:
  On Thu, Feb 14, 2013 at 5:58 AM, Ashok C ash@gmail.com wrote:
  
   As part of implementing certificate expiry related alarms for my SSL
   application, I would kindly require few suggestions and clarifications
   from the community.
  ...
 
  There are two hidden issues: (1) what precisely is warranted, and (2)
  what liability is in play. Good luck in pinning a CA on liability (100
  page plus CPSs).
 
  Not clear what you exactly meant here. Could you please put it in more
  simpler terms? Thanks.
 
 Read the chapter on PKI from Peter Gutmann's Security Engineering (pp.
 595-650, www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

 It's not dry reading. Its interesting from a technical POV (what's the
 problem, how is it being solved); from a historical POV (committee
 disagreements, past failures, etc); and it's somewhat humorous at
 times (Gutmann has a witty sense of humor).

 Jeff

Re: Certificate expiry alarms Reg.

[Ashok C]

Thanks Jeff,
My response inline.

On Thu, Feb 14, 2013 at 5:31 PM, Jeffrey Walton noloa...@gmail.com wrote:

 On Thu, Feb 14, 2013 at 5:58 AM, Ashok C ash@gmail.com wrote:
  Hi,
 
  As part of implementing certificate expiry related alarms for my SSL
  application, I would kindly require few suggestions and clarifications
 from
  the community.
 Does that include OSCP checking? On a continuous basis? The CA will
 not warrant a certificate if its on a CRL. It does not matter when you
 get the list.

 Did you mean OCSP? If yes, no. I'm not considering OCSP. Also, currently
I'm not considering CRLs also.


  1. What are the different allowed time zones in a certificate? As per the
  RFC, I understand that only GMT and Generalized time are allowed, but
 can I
  consider this as a mandate? I remember seeing certificates containing the
  date information in other time zones, so wanted to confirm this.
 Time Zones are strictly presentation. The only time is GMT or UTC. It
 does not matter if its the fellow in the bearskin hat looking up at
 noon or an atomic clock.

Ok, that's good news :)


  2. I was planning to implement midnight check for certificate expiry. But
  can this be a problem? As I understand, certificates need not expire at
  midnight but basically at any point of time.
 The CA will not warrant a certificate if its beyond notAfter.

Yes, I got this point. So ideally I should raise the alarm then and there I
guess. Right?


  Let us say the end entity certificate expires at 12:00:01 AM, so my
 expiry
  alarm will be raised potentially after 23:59:59 hours.
  What is the impact of me not raising this alarm immediately? And I would
  want to understand the impact to both a server application as well as a
  client application separately. In my point of view, server/client will
 not
  be able to establish SSL connections during this time period(~24 hours),
 but
  how big would be this impact?

 There are two hidden issues: (1) what precisely is warranted, and (2)
 what liability is in play. Good luck in pinning a CA on liability (100
 page plus CPSs).

Not clear what you exactly meant here. Could you please put it in more
simpler terms? Thanks.


 Jeff
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine

[Ashok C]

Thanks Steve and Kent for the pointers.
Makes things clear for now.

On Thu, Dec 6, 2012 at 4:22 AM, Dr. Stephen Henson st...@openssl.orgwrote:

 On Wed, Dec 05, 2012, Ashok C wrote:

  Hi,
 
  Our current SSL server loads plain-text private keys using the
  SSL_CTX_use_PrivateKey_file()
  method. We are moving from this strategy to use custom encrypted private
  keys using the TPM concept. For this, we have an engine implemented. Now
  the question is this.
 
  Does my SSL server need to change from loading private keys using
  SSL_CTX_use_PrivateKey_file()
  method to use this method -- ENGINE_load_private_key(ENGINE *e, const
 char
  *key_id,
 
  UI_METHOD *ui_method, void *callback_data)
 
 

 You can't use SSL_CTX_use_PrivateKey_file to load an ENGINE specific key.
 Instead you use ENGINE_load_private_key() to load the key into an EVP_PKEY
 structure and then pass that to SSL_CTX_use_PrivateKey().

 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: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi,

One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.

--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 /Charles/



 Windows has built in support for using and checking time stamping
 countersignatures in PKCS7 signatures.  If the countersignature is signed
 with a currently valid certificate with the time stamping
 extended usage enabled, then the outer PKCS7 signature and its certificate
 is checked as if the current time was the one certified
 by the time stamp (but still using up to date revocation
 information, paying attention to revocation reasons and dates).

 Thus the Windows certificate store has good reason to keep around
 expired CA certificates going back to ca. 1996 (when Microsoft
 released the first version supporting time stamped signatures).

 P.S.

 I see no technical reason why such time stamp countersignature
 support could not be added to the OpenSSL core code.

 The validation side implementation involves a few standard OIDs
 (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 1.2.840.113549.1.9.6
 = counterSignature
 unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
 authenticated attribute).  The countersignature specifies the
 signed data type to be 1.2.840.113549.1.7.1=data, but the
 signed data is really the encryptedDigest/signatureValue from
 the enclosing SignerInfo being countersigned (as per
 PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
 a counterSignature made by an entity with the timeStamping
 extended key usage is simply the standard signingTime
 authenticated attribute in the counterSignature itself.

 On the signing side, the signer simply submits his
 encryptedDigest/signatureValue to a time stamping service he has
 a contract with, using a simplified historic protocol as follows:

 POST url with Accept: application/octet-string Content-Type:
 application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
   type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
   SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
  content Type OID -- must be 1.2.840.113549.1.7.1 =data
  content [0] EXPLICIT OCTET STRING
 -- must be the outer encryptedDigest
  }
   }
 }

 Response if successful is a 200 HTTP status with Content-Type:
 application/octet-string and a value which is Base64 of DER of
 a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
 from the request. The time is indicated by the standard
 signingTime authenticated attribute in the only SignerInfo in
 signerInfos)

 This historic time stamping protocol is necessary because the
 RFC3161 protocol returns a signature which is not a valid RFC2985
 counterSignature.

 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 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: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..

Ashok
On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com wrote:

 Hi,

 In your test case which fields actually differ between the
 old root CA certificate and the new root CA certificate?

 P.S.

 Please do not use those 3 letter abbreviations of certificate
 field names, very few people know those abbreviations.

 For the benefit of other readers:

 I think Ashok was referring to AuthorityKeyIdentifier and
 SubjectKeyIdentifier fieldsbeing absent from the root
 CA certificates in his scenario.

 On 9/24/2012 6:26 PM, Ashok C wrote:

 Hi,

 One more observation was made here in another test case.
 _*Configuration:*_
 One old root CA certificate oldca.pem with subject name say, C=IN
 One new root CA certificate newca.pem with same subject name.
 One EE certificate, ee.pem issued by new root CA.

 _*Test case 1:*_
 Using CAFile option in openssl verify of the ee.pem,
 If oldca.pem is placed on top and newca.pem below, verification fails.
 i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

 _*Test case 2:*_
 If newca.pem is placed on top and oldca.pem below that, verification
 succeeds.
 i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

 Test case 1 does not seem to correct behaviour as the trust store
 contains newca.pem. Ideally the lookup needs to verify ee.pem with the
 newca.pem.

 P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
 fields.

 --
 Ashok


 On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com
 mailto:jb-open...@wisemo.com** wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate from the
 Windows
 store? Duplicate expired/non expired CA certificates sounds to
 me like a
 problem waiting to happen.

 /Charles/



 Windows has built in support for using and checking time stamping
 countersignatures in PKCS7 signatures.  If the countersignature is
 signed with a currently valid certificate with the time stamping
 extended usage enabled, then the outer PKCS7 signature and its
 certificate is checked as if the current time was the one certified
 by the time stamp (but still using up to date revocation
 information, paying attention to revocation reasons and dates).

 Thus the Windows certificate store has good reason to keep around
 expired CA certificates going back to ca. 1996 (when Microsoft
 released the first version supporting time stamped signatures).

 P.S.

 I see no technical reason why such time stamp countersignature
 support could not be added to the OpenSSL core code.

 The validation side implementation involves a few standard OIDs
 (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
 1.2.840.113549.1.9.6 = counterSignature
 unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
 authenticated attribute).  The countersignature specifies the
 signed data type to be 1.2.840.113549.1.7.1=data, but the
 signed data is really the encryptedDigest/signatureValue from
 the enclosing SignerInfo being countersigned (as per
 PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
 a counterSignature made by an entity with the timeStamping
 extended key usage is simply the standard signingTime
 authenticated attribute in the counterSignature itself.

 On the signing side, the signer simply submits his
 encryptedDigest/signatureValue to a time stamping service he has
 a contract with, using a simplified historic protocol as follows:

 POST url with Accept: application/octet-string Content-Type:
 application/octet-string The post data is Base64 of DER of
 SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
   content Type OID -- must be 1.2.840.113549.1.7.1 =data
   content [0] EXPLICIT OCTET STRING
  -- must be the outer encryptedDigest
   }
}
  }

 Response if successful is a 200 HTTP status with Content-Type:
 application/octet-string and a value which is Base64 of DER of
 a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
 from the request. The time is indicated by the standard
 signingTime authenticated attribute in the only SignerInfo in
 signerInfos)

 This historic time stamping protocol is necessary because the
 RFC3161 protocol returns a signature which is not a valid RFC2985
 counterSignature.

 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Thanks Jacob, but in the three scenarios you mentioned, the first one *does
not* seem to be supported by openssl 1.0.0*. I think that was the subject
of this email thread in the beginning.

1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.

Here, if the expired one is encountered first, openSSL does not lookup the
non-expired CA certificate. This is then a bug right?

--
Ashok



On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm jb-open...@wisemo.com wrote:

 Does that work with any other serious X.509 validation toolkit?

 To make this work (assuming the old root CA cert has not yet expired), the
 validation code will need to actually verify the End Entity
 certificate against both public keys, which effectively reduces the
 algorithm security by allowing twice as many bit strings to be
 accepted as valid.

 Filtering based on criteria that do not involve actual signature
 validation would be cryptographically safe, but when falling back to
 validating against multiple signatures, extra care is needed for the
 above reason.

 As for trust anchor update scenarios, I know of 3 different scenarios
 that should be accepted by any good X.509 validation algorithm:

 1. Changing expiry or other attributes while keeping the key.
 Here the CA issues a new self-signed certificate with updated
 attributes but unchanged key.

 2. Changing the CA key when the old key has *not* been compromised.
 Here the CA generates a new key and issues two certificates for it:

A. A self-signed new root with a serial number or other variation
  in one of the subject name components.
B. A certificate for the new key and the same subject and (optional)
  SubjectKeyIdentifier as A, but issued by the old root certificate
  identity and key.

 End Entities with certificates issued with the new key reference the
 modified subject as authority and should be configured to supply the
 transitional B certificate in chains sent to other end entities.
 Such end entities should then succeed validating against either the
 old root CA (via the B certificate supplied) or the new root CA
 (via finding it as a locally configured trust anchor).

 This is the scenario used by at least one major CA for its upgrade
 to larger keys, and SSL servers that forget the B certificate in
 the supplied chain get rejected by at least one common platform
 version (Android 2.3) because it only includes the old trust
 root in its store and uses an underdocumented BouncyCastly store
 format thus preventing the efficient deployment of the new A cert.

 3. Setting up the CA to have keys for more than one algorithm (such
 as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
 certificate validation could SHOULD (but might not) match issued end
 entity certificates to the trust anchor by also comparing
 signatureAlgorithm in the issued certificate against
 subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
 store.

 However because not all clients are going to do that, it is still
 recommended that the CA follows the scenario 2 procedures, except
 when it is a test CA for verifying handling of this scenario in
 X.509 implementations.


 On 9/24/2012 8:01 PM, Ashok C wrote:

 Only the private and public keys are different.. Rest of the fields are
 same.. Basically I am simulating the trust anchor update related
 scenarios..
 And yes Jacob, thanks for indicating, I'll make sure I don't use such
 abbreviations from here on..

 Ashok

 On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com
 mailto:jb-open...@wisemo.com** wrote:

 Hi,

 In your test case which fields actually differ between the
 old root CA certificate and the new root CA certificate?

 P.S.

 Please do not use those 3 letter abbreviations of certificate
 field names, very few people know those abbreviations.

 For the benefit of other readers:

 I think Ashok was referring to AuthorityKeyIdentifier and
 SubjectKeyIdentifier fieldsbeing absent from the root
 CA certificates in his scenario.

 On 9/24/2012 6:26 PM, Ashok C wrote:

 Hi,

 One more observation was made here in another test case.
 _*Configuration:*_
 One old root CA certificate oldca.pem with subject name say, C=IN
 One new root CA certificate newca.pem with same subject name.
 One EE certificate, ee.pem issued by new root CA.

 _*Test case 1:*_
 Using CAFile option in openssl verify of the ee.pem,
 If oldca.pem is placed on top and newca.pem below, verification
 fails.
 i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

 _*Test case 2:*_
 If newca.pem is placed on top and oldca.pem below that,
 verification
 succeeds.
 i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

 Test case 1 does not seem

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Gentle reminder ..
Just want to know if this is a bug or intended behaviour.

--
Ashok

On Fri, Sep 14, 2012 at 3:12 PM, Ashok C ash@gmail.com wrote:

 Hi Etkal,

 s_client app or the OpenSSL cert store functionality that changed this.
 The problem is with the openSSL store itself, as I had tested this with my
 own SSL client and observed the same behaviour.

 --
 Ashok

 On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote:

 I suppose that’s a workaround, but doesn’t address the root cause.
 Windows can quite happily handle expired certificates still hanging out in
 trusted stores; I see this all the time as root updates occur and renewed
 certificates are installed.  It seems that a change in OpenSSL broke the
 previous behaviour that allowed this as well, though we can’t tell if it’s
 the s_client app or the OpenSSL cert store functionality that changed this.
 


 
 *Erik Tkal**
 *Juniper OAC/UAC/Pulse Development

 

 ** **

 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
 *Sent:* Thursday, September 13, 2012 9:42 AM
 *To:* openssl-users@openssl.org
 *Subject:* RE: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 ** **

 *Charles*

 *From:* owner-openssl-us...@openssl.org [
 mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org]
 *On Behalf Of *Ashok C
 *Sent:* Thursday, September 13, 2012 12:49 AM
 *To:* openssl-users@openssl.org
 *Subject:* Re: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Sending again as the previous email did not appear in list.
 Is there some problem with the mailing list?

 --
 Ashok

 On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok

 ** **

 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 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): 00e49efdf33ae80ecfa5113e19a4240232
 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): 70bae41d10d92934b638ca7b03ccbabf
 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 openssl versions?

 Thanks
 Klaus

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org***
 *

 ** **

 ** **

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi Etkal,

s_client app or the OpenSSL cert store functionality that changed this.
The problem is with the openSSL store itself, as I had tested this with my
own SSL client and observed the same behaviour.

--
Ashok

On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote:

 I suppose that’s a workaround, but doesn’t address the root cause.
 Windows can quite happily handle expired certificates still hanging out in
 trusted stores; I see this all the time as root updates occur and renewed
 certificates are installed.  It seems that a change in OpenSSL broke the
 previous behaviour that allowed this as well, though we can’t tell if it’s
 the s_client app or the OpenSSL cert store functionality that changed this.
 


 
 *Erik Tkal**
 *Juniper OAC/UAC/Pulse Development

 

 ** **

 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
 *Sent:* Thursday, September 13, 2012 9:42 AM
 *To:* openssl-users@openssl.org
 *Subject:* RE: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 ** **

 *Charles*

 *From:* owner-openssl-us...@openssl.org [
 mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org]
 *On Behalf Of *Ashok C
 *Sent:* Thursday, September 13, 2012 12:49 AM
 *To:* openssl-users@openssl.org
 *Subject:* Re: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Sending again as the previous email did not appear in list.
 Is there some problem with the mailing list?

 --
 Ashok

 On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok

 ** **

 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 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): 00e49efdf33ae80ecfa5113e19a4240232
 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): 70bae41d10d92934b638ca7b03ccbabf
 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 openssl versions?

 Thanks
 Klaus

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

 ** **

 ** **

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok

On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok


 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 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 openssl versions?

 Thanks
 Klaus

 __**__**
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
klaus.mailingli...@pernau.at wrote:

 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 openssl versions?

 Thanks
 Klaus

 __**__**__
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

How to find correct issuer certificate in multi-level hierarchy?

[Ashok C]

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?

[Ashok C]

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

Re: [openssl] Forming the correct chain for an end entity certificate Reg.

[Ashok C]

Thanks Dave. That clarifies part of my question.
The next part is regarding cross certificates. For the normal multilevel
hierarchy, AKI check seems to be sufficient to identify the correct CA in
the chain.
But when cross certificates come into the picture, will the AKI checks
still hold good? I hear they are not. Would you have some
opinion/understanding regarding this?

--
Ashok

On Mon, Jul 30, 2012 at 8:17 AM, Dave Thompson dthomp...@prinpay.comwrote:

 From: Ashok C [mailto:ash@gmail.com]
 Sent: Saturday, 28 July, 2012 01:21

 Thanks Dave. But main use case for me is the trust anchor update case.
 I have a certain requirement which goes like this:
 I have a client application which runs on my machine and it will attempt
 to connect to multiple remote servers.
 At time T0:
 Client has old root. All servers have old end entity, connection goes
 fine.
 At time T1:
 Trust anchor updates itself and my client gets hold of the new root.
 But at the same time it will not delete the old root since some servers
 would not yet have procured the new end entity from the new root.
 At this time, both roots would be present in my trust store. And I will
 need to form the right certificate chain ... For this, I would need
 the AKI/SKI related checks. Since the issuer-id subject-name fields
 of both old as well as new root would be same.

 Will they? Most public CAs use different names. *Similar*, like
 Verisign blah blah G3 and Verisign blah blah G4, but different.

 If you are using a CA where DN is kept the same, yes you need AKI*,
 or else you need to do trial and error. Good luck. (* Technically
 this could be AKI-IssuerAndSerial, as long as serial is unique,
 instead of AKI-SKI. But I've not seen anyone use that.)

 And regarding the some even don't have AKI/SKI, I read the RFC and
 it mandates the presence of these extensions in all conforming CAs.

 Conforming, yes. In the real world, it isn't always true that everybody
 conforms. But at least when they're not conforming, you can tell your
 users to blame them. That usually helps for about 5 minutes.

Re: [openssl] Forming the correct chain for an end entity certificate Reg.

[Ashok C]

Also adding openSSL community into loop.

Thanks Dave. But main use case for me is the trust anchor update case.
I have a certain requirement which goes like this:
I have a client application which runs on my machine and it will attempt to
connect to multiple remote servers.
*At time T0:*
Client has old root. All servers have old end entity, connection goes fine.
*At time T1:*
Trust anchor updates itself and my client gets hold of the new root. But at
the same time it will not delete the old root since some servers would not
yet have procured the new end entity from the new root.
At this time, both roots would be present in my trust store. And I will
need to form the right certificate chain for a display command which should
display: new EE--new root. And not new EE--old root. For this, I would
need the AKI/SKI related checks. Since the issuer-id subject-name fields of
both old as well as new root would be same.

And regarding the some even don't have AKI/SKI, I read the RFC and it
mandates the presence of these extensions in all conforming CAs.
--
Ashok

On Fri, Jul 27, 2012 at 4:18 AM, Dave Thompson dthomp...@prinpay.comwrote:

 **
 I'm not certain that actually works as described.

 I see the checks in crypto/x509/x509_vfy.c and crypto/x509v3/v3_purp.c,
 but the 'search for parent' part has multiple options spread over several
 sourcefiles --
 the standard ways are to look in a file commonly designated CAfile and/or
 a directory commonly designated CApath, but there are several ways to
 extend this.
 There are comments on x509_lu.c _get1_issuer, but I'm not sure if/when
 they apply.

 It has never been an issue for me, because all the CAs I've seen
 have distinct DN's for each cert they issue, i.e. they never need
 to disambiguate using AKI/SKI. And some don't even *have* AKI/SKI.

 Good luck.

  --
 *From:* Ashok C [mailto:ash@gmail.com]
 *Sent:* Thursday, 26 July, 2012 02:08
 *To:* Dave Thompson
 *Subject:* Fwd: Forming the correct chain for an end entity certificate
 Reg.

 Hi Dave,

 Could you please help me on this?

 --
 Ashok

 -- Forwarded message --
 From: Ashok C ash@gmail.com
 Date: Mon, Jul 23, 2012 at 12:11 PM
 Subject: Forming the correct chain for an end entity certificate Reg.
 To: openssl-users@openssl.org


 Hi,

 I have a requirement to form a correct certificate chain (for a server
 application, to send to client).
 Currently I was forming the chain using the issuer-id and subject name
 combination alone.
 Eg: The algorithm followed was:
 Let End entity(server certificate) be called as 'E'. Root certificate as
 'R' , and intermediate CA certificate be 'I'.


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name and add it to chain. This is I. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Since for 'R' issuer-id and
subject-name are same, this is considered to be root and hence not added to
chain.

 But, I find that this chain is not conclusive enough, as
 subject-name==issuer-id is not a complete criteria for a root certificate
 and also that I cannot be treated as issuer of E just because of the
 success of the issuer-id/subject-name checks.
 I read the openSSL verify man page and understood that checks related to
 authority key identifier and subject key identifier are required to decide
 upon the correct chain.

 So I presume that the logic should be modified to look something like this:


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name. This is I. Check if authority key identifier of E is the
same as the subject key identifier of I. If this is true, add it to
chain. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Check if authority key
identifier of I is the same as the subject key identifier of R. 'R' can
be concluded as the root only if subject-name==issuer-id and
authority-key-identifier==subject-key-identifier.

 Is this solution complete for a multi-level hierarchy? As of now, I do not
 have to deal with cross-certification, though I am very interested to know
 from you guys on the complications involved when that comes into the
 picture. I understand there is RFC 4158 explaining this path formation, but
 was wondering that needs to be read in detail only for the
 cross-certification related parts.

 Does openSSL have any sample implementation somewhere for this path
 formation(subject-key/authority-key checks) which I could use for reference?
 Thanks in advance.

 Regards,
 Ashok

Re: Forming the correct chain for an end entity certificate Reg.

[Ashok C]

Hi,

Could someone please confirm the points I mentioned in the previous email?
Also wanted to understand on how to identify cross certificates using
openSSL. I understand that the AKI checks are not sufficient when  cross
certificates are present in my certificate chain.

--
Ashok

On Mon, Jul 23, 2012 at 2:09 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I read from the RFC5280 that AKI is mandatory for all certificates
 generated by a conforming CA.
 The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction.  There is one exception;
where a CA distributes its public key in the form of a self-signed
certificate, the authority key identifier MAY be omitted.  The
signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key.  (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.

 And that Subject Key Identifier is MUST for CA certificates but only
 SHOULD for end entity certificates.

 For end entity certificates, the subject key identifier extension
provides a means for identifying certificates containing the
particular public key used in an application.  Where an end entity
has obtained multiple certificates, especially from multiple CAs, the
subject key identifier provides a means to quickly identify the set
of certificates containing a particular public key.  To assist
applications in identifying the appropriate end entity certificate,
this extension SHOULD be included in all end entity certificates.

 I am going to support only v3 certificates in which the above extensions
 seem to be MUST(For EE I don't need the SKI to be processed anyways, AKI is
 sufficient).
 So the go ahead I would need from the community is whether the AKI/SKI
 checks are sufficient for chain formation in a v3 PKI or not.

 --
 Ashok

  On Mon, Jul 23, 2012 at 1:48 PM, Sukalp Bhople bsuk...@gmail.com wrote:

 Hi Ashok,

 If you have a look at the v3_purp.c,

 You can follow following algorithm:
 1. check issuer name, if okay then proceed or exit.
 2. check akid,
 3. check the key usage ... (if the issuer certificate in the chain for a
 subject under consideration is allowed to sign or not),
 4. check the path length constraint., and check for proxy certificates.

 As far as understood from openssl source code, it checks the akid only if
 it is present in the certificate otherwise it only depends on the subject
 name and issuer name match.

 Of course, at the end you need to verify the signature. But thats not the
 part of the certificate chain formation.


 On Mon, Jul 23, 2012 at 10:06 AM, Ashok C ash@gmail.com wrote:

 Thanks Sukalp,

 But I would like confirmation for the algorithm also.
 Whether SKI/AKI related checks are sufficient for the chain formation,
 or if anything else needs to be checked.

 --
 Ashok


 On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople bsuk...@gmail.comwrote:

 Hi,

 You can have a look at following files from openssl source code.

 1. ssl_cert.c (around line number 626)
 2. x509_vfy.c (around line number 153)
 3. v3_purp.c (around line number 700).

 good luck!

 On Mon, Jul 23, 2012 at 8:41 AM, Ashok C ash@gmail.com wrote:

 Hi,

 I have a requirement to form a correct certificate chain (for a server
 application, to send to client).
 Currently I was forming the chain using the issuer-id and subject name
 combination alone.
 Eg: The algorithm followed was:
 Let End entity(server certificate) be called as 'E'. Root certificate
 as 'R' , and intermediate CA certificate be 'I'.


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step:
E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name and add it to chain. This is I. Chain at this step: 
 E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Since for 'R' issuer-id and
subject-name are same, this is considered to be root and hence not 
 added to
chain.

 But, I find that this chain is not conclusive enough, as
 subject-name==issuer-id is not a complete criteria for a root certificate
 and also that I cannot be treated as issuer of E just because of the
 success of the issuer-id/subject-name checks.
 I read the openSSL verify man page and understood that checks related
 to authority key identifier and subject key identifier are required to
 decide upon the correct chain.

 So I presume that the logic should be modified to look something like
 this:


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step:
E
2. Search trust store for CA certificate which has this 'C

Re: Forming the correct chain for an end entity certificate Reg.

[Ashok C]

Thanks Sukalp,

But I would like confirmation for the algorithm also.
Whether SKI/AKI related checks are sufficient for the chain formation, or
if anything else needs to be checked.

--
Ashok

On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople bsuk...@gmail.com wrote:

 Hi,

 You can have a look at following files from openssl source code.

 1. ssl_cert.c (around line number 626)
 2. x509_vfy.c (around line number 153)
 3. v3_purp.c (around line number 700).

 good luck!

 On Mon, Jul 23, 2012 at 8:41 AM, Ashok C ash@gmail.com wrote:

 Hi,

 I have a requirement to form a correct certificate chain (for a server
 application, to send to client).
 Currently I was forming the chain using the issuer-id and subject name
 combination alone.
 Eg: The algorithm followed was:
 Let End entity(server certificate) be called as 'E'. Root certificate as
 'R' , and intermediate CA certificate be 'I'.


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name and add it to chain. This is I. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Since for 'R' issuer-id and
subject-name are same, this is considered to be root and hence not added 
 to
chain.

 But, I find that this chain is not conclusive enough, as
 subject-name==issuer-id is not a complete criteria for a root certificate
 and also that I cannot be treated as issuer of E just because of the
 success of the issuer-id/subject-name checks.
 I read the openSSL verify man page and understood that checks related to
 authority key identifier and subject key identifier are required to decide
 upon the correct chain.

 So I presume that the logic should be modified to look something like
 this:


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name. This is I. Check if authority key identifier of E is the
same as the subject key identifier of I. If this is true, add it to
chain. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Check if authority key
identifier of I is the same as the subject key identifier of R. 'R' 
 can
be concluded as the root only if subject-name==issuer-id and
authority-key-identifier==subject-key-identifier.

 Is this solution complete for a multi-level hierarchy? As of now, I do
 not have to deal with cross-certification, though I am very interested to
 know from you guys on the complications involved when that comes into the
 picture. I understand there is RFC 4158 explaining this path formation, but
 was wondering that needs to be read in detail only for the
 cross-certification related parts.

 Does openSSL have any sample implementation somewhere for this path
 formation(subject-key/authority-key checks) which I could use for reference?
 Thanks in advance.

  Regards,
 Ashok




 --
 Regards,
 *Sukalp Bhople.*

Re: Forming the correct chain for an end entity certificate Reg.

[Ashok C]

Hi,

I read from the RFC5280 that AKI is mandatory for all certificates
generated by a conforming CA.
The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.  There is one exception;
   where a CA distributes its public key in the form of a self-signed
   certificate, the authority key identifier MAY be omitted.  The
   signature on a self-signed certificate is generated with the private
   key associated with the certificate's subject public key.  (This
   proves that the issuer possesses both the public and private keys.)
   In this case, the subject and authority key identifiers would be
   identical, but only the subject key identifier is needed for
   certification path building.

And that Subject Key Identifier is MUST for CA certificates but only
SHOULD for end entity certificates.

For end entity certificates, the subject key identifier extension
   provides a means for identifying certificates containing the
   particular public key used in an application.  Where an end entity
   has obtained multiple certificates, especially from multiple CAs, the
   subject key identifier provides a means to quickly identify the set
   of certificates containing a particular public key.  To assist
   applications in identifying the appropriate end entity certificate,
   this extension SHOULD be included in all end entity certificates.

I am going to support only v3 certificates in which the above extensions
seem to be MUST(For EE I don't need the SKI to be processed anyways, AKI is
sufficient).
So the go ahead I would need from the community is whether the AKI/SKI
checks are sufficient for chain formation in a v3 PKI or not.

--
Ashok

On Mon, Jul 23, 2012 at 1:48 PM, Sukalp Bhople bsuk...@gmail.com wrote:

 Hi Ashok,

 If you have a look at the v3_purp.c,

 You can follow following algorithm:
 1. check issuer name, if okay then proceed or exit.
 2. check akid,
 3. check the key usage ... (if the issuer certificate in the chain for a
 subject under consideration is allowed to sign or not),
 4. check the path length constraint., and check for proxy certificates.

 As far as understood from openssl source code, it checks the akid only if
 it is present in the certificate otherwise it only depends on the subject
 name and issuer name match.

 Of course, at the end you need to verify the signature. But thats not the
 part of the certificate chain formation.


 On Mon, Jul 23, 2012 at 10:06 AM, Ashok C ash@gmail.com wrote:

 Thanks Sukalp,

 But I would like confirmation for the algorithm also.
 Whether SKI/AKI related checks are sufficient for the chain formation, or
 if anything else needs to be checked.

 --
 Ashok


 On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople bsuk...@gmail.comwrote:

 Hi,

 You can have a look at following files from openssl source code.

 1. ssl_cert.c (around line number 626)
 2. x509_vfy.c (around line number 153)
 3. v3_purp.c (around line number 700).

 good luck!

 On Mon, Jul 23, 2012 at 8:41 AM, Ashok C ash@gmail.com wrote:

 Hi,

 I have a requirement to form a correct certificate chain (for a server
 application, to send to client).
 Currently I was forming the chain using the issuer-id and subject name
 combination alone.
 Eg: The algorithm followed was:
 Let End entity(server certificate) be called as 'E'. Root certificate
 as 'R' , and intermediate CA certificate be 'I'.


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name and add it to chain. This is I. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Since for 'R' issuer-id and
subject-name are same, this is considered to be root and hence not 
 added to
chain.

 But, I find that this chain is not conclusive enough, as
 subject-name==issuer-id is not a complete criteria for a root certificate
 and also that I cannot be treated as issuer of E just because of the
 success of the issuer-id/subject-name checks.
 I read the openSSL verify man page and understood that checks related
 to authority key identifier and subject key identifier are required to
 decide upon the correct chain.

 So I presume that the logic should be modified to look something like
 this:


1. Look up E's issuer-id. Let it be 'C=IN'.  Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name. This is I. Check if authority key identifier of E is 
 the
same as the subject key identifier of I. If this is true, add it to
chain. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Check if authority key
identifier of I is the same as the subject key identifier of R. 'R

Unique naming convention that can be used for certificates Reg.

[Ashok C]

Hi,

What would be the unique names with which I can store CA certificates in
file system?
I understand that issuer-id and serial number are the unique identifiers
for a certificate. But using this name for a certificate file name makes it
very long and also introduces some characters like @,= etc, which I
consider undesirable for file naming.
I considered using serial number, but one more thing I want to achieve is
that by looking at the file name I should be able to identify what
certificate it actually is. Eg: verisign-subca3.pem would mean that this is
the 3rd subordinate CA from verisign.
These certificates are copied to the filesystem by my application and I
need to generate these names from the certificates and also make sure that
each name is unique and does not clash in any way and also in compliance
with the UNIX file naming standards.

Regds,
Ashok

Re: expired ssl certificate

[Ashok C]

Hi,

I had almost the same requirement and eventually achieved it by patching my
openssl package's x509_verify code to do the check_cert_time() method
optionally depending on some conditions. Ideally I feel openSSL should
provide a validation flag like
*X509_V_FLAG_IGNORE_LIFETIME **which would help in this case. I can see
many existing flags listed here.** *
http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html#VERIFICATION_FLAGS

Is there any specific reason as to why OpenSSL does not want to support
this feature?


Regds,
Ashok


On Thu, Apr 12, 2012 at 12:26 AM, Erwin Himawan ehima...@gmail.com wrote:

 Reading Nou's proposal, I have the impression that the client needs to be
 modified to accept expired server's certificate.  Is my understanding
 correct? If my understanding is corrrect, the client needs to be updated.

 If the client needs to be updated, In my opinion, it is simpler to update
 the client with a new server certificate.
 However, you should not use a selfsigned certificate for your serve
 certificate.  Instead, I am proposing to create a chain of certificate
 (PKI).  You could avoid this problem in the future by creating a simple
 PKI.  FUrther you could expand this PKI to issue certificate for other
 application.

 This is what I am proposing:
 1. Create a long lived self-signed CA certificate (for example: 20 or 30
 years); This self-signed certificate is called trust anchor certificate.
 Make sure, basic constraint CA is set to true.
 Do not make the expiration less than 5 years, since you will have the
 same issue again in the next 5 year to roll-over your trust anchor
 certificate. Also, keep the private key of this CA as safe as possible.
  THis is your root of trust. If you compromise this root CA private key,
 your PKI becomes void.
 2. Distribute this self-signed certificate to all clients and install this
 as the trusted certificate.
 3. Have this self-signed CA (trust anchor) created in step-1 issues the
 server certificate.  For this server certificate, validity period does not
 matter. Of course you do not want to make the  validity period too short
 since you have to frequently update the server certificate when it is
 expired.

 Using this proposed method, you can update or change the server
 certificate as often as you like.
 The server certificate is typically included in the SSL's ServerHello
 message, so the client always got the server certificate during SSL
 handshake. I think (?) the server could also include the chain of
 certificate up to the trust anchor certificate.

 When the client receives the server certificate issued by the self-signed
 CA (the self-signed CA certificate could also be included in the
 ServerHello), the client can verify this certificate chain up to the
 self-signed CA certificate. If the chain can be verified, then the server
 certificate is successfully validated. Hence, the server can be
 cryptographically authenticated.

 Using Nou's proposal, your client would practically accept any self-signed
 certificate and prone to man-in-the-middle attack.  The client can
 cryptographically verify the server certificate, but the client can not
 cryptographically authenticate the server since the client does not have
 the knowledge of the server's legitimate public key. Using my proposal,
 your client can cryptographically authenticate the server, by verifying the
 digital signature in the server's certificate using the (selfsigned) CA
 certificate.  The selfsigned CA certificate is then verified against a list
 of trusted certificates. My proposal is actually similar with what you are
 doing currently. The difference between my proposal and yours is: in yours,
 you verify the server certificate against a list of trusted certificates.
 In my proposal, you verify the server certificate using the CA certificate
 which is in a list of trusted certificates.

 Erwin


 On Wed, Apr 11, 2012 at 11:34 AM, Nou Dadoun ndad...@teradici.com wrote:

 I'm no ssl guru either but I'll make some brief comments and let others
 jump in if I'm too far off the mark.

 1.  If you use the standard verify and the peer presents an expired
 certificate, the certificate will not be verified and the connection will
 fail.

 2.  The verification callback is called after the regular verification
 is performed, here's a simple example I posted with my own question
 yesterday:

 static int verify_callback(int ok, X509_STORE_CTX *stor)
 {
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
 }

 The ok parameter tells you whether the certificate passed so that if it's
 not ok (didn't pass) you can examine the reason/error and the certificate
 itself to see whether or not you want to over-rule that result. The return
 value indicates whether you want to accept it or 

Re: Is CRL verification automatic in openSSL?

[Ashok C]

Hi,

On further investigation, we have found that the addition of the following
piece of code enables the CRL checking.

X509_STORE *store = getStore();



// Enable CRL checking

X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();

X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK);

X509_STORE_set1_param(store, param);
X509_VERIFY_PARAM_free(param);

And it is also clear that we need to use SSL_CTX_load_verify_locations() is
required to be used to load CA certificate + CRL concatenated into a PEM
file.(Alternatively CAPath also, but we did not try that yet).

I guess my problems are solved for now. If you guys have any comments on
this, please let me know. Otherwise you can ignore the previous email.

Regds,
Ashok

On Wed, Mar 28, 2012 at 10:08 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I am implementing CRL feature for my application and was doing a proof of
 concept using openSSL.
 Here is what I did:

1. I used openssl commands to generate a v3 root CA certificate and
also the corresponding server certificate.
2. Now i revoked the server certificate using openssl commands.
3. First I tested this with the openSSL s_client and s_server. I
understood from googling, that I need to use the -crl-check option in the
s_client side to do the CRL validation and as instructed in the reference
manual, I concatenated my CA certificate as well as the CRL into a single
PEM file and passed it to openssl client in the -CAFile field.
4. Things went as expected and I got the error code for CRL validation
failure.
5. Next step, I wanted to do the same for my sample SSL client and
server.
6. Here, from my client side, I loaded the concatenated cert + crl
into combined.pem and loaded it using
7. SSL_CTX_load_verify_locations(ctx,combined.pem,NULL). While doing
the SSL connection, I found that the CRL _was not_ checked. (I understand
now that this is NOT the API to set the CRL into verification paths)
8. Later, from further reading I understood that CRL check is not done
by default and I need to add the CRL to the verification paths using X509
level APIs. (

 http://stackoverflow.com/questions/4389954/does-openssl-automatically-handle-crls-certificate-revocation-lists-now
)

 

 X509_STORE *store = getStore();



 // Enable CRL checking

 X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();

 X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK);

 X509_STORE_set1_param(store, param);

 X509_VERIFY_PARAM_free(param);
 

 I am going to try this out now, but before that , wanted to check with the
 community:

- If the way I am proceeding is correct?
- Are there any other simpler ways to do this?
- What would be best approach to follow for CRL checking enabling?
- Are there any SSL_CTX level APIs for this now?


 I am using openssl version openssl-0.9.8r(Also wanted to know if this
 behaviour has changed in higher versions of openssl)
 Thanks in advance!

 Regds,
 Ashok

Is CRL verification automatic in openSSL?

[Ashok C]

Hi,

I am implementing CRL feature for my application and was doing a proof of
concept using openSSL.
Here is what I did:

   1. I used openssl commands to generate a v3 root CA certificate and also
   the corresponding server certificate.
   2. Now i revoked the server certificate using openssl commands.
   3. First I tested this with the openSSL s_client and s_server. I
   understood from googling, that I need to use the -crl-check option in the
   s_client side to do the CRL validation and as instructed in the reference
   manual, I concatenated my CA certificate as well as the CRL into a single
   PEM file and passed it to openssl client in the -CAFile field.
   4. Things went as expected and I got the error code for CRL validation
   failure.
   5. Next step, I wanted to do the same for my sample SSL client and
   server.
   6. Here, from my client side, I loaded the concatenated cert + crl into
   combined.pem and loaded it using
   7. SSL_CTX_load_verify_locations(ctx,combined.pem,NULL). While doing the
   SSL connection, I found that the CRL _was not_ checked. (I understand now
   that this is NOT the API to set the CRL into verification paths)
   8. Later, from further reading I understood that CRL check is not done
   by default and I need to add the CRL to the verification paths using X509
   level APIs. (
   
http://stackoverflow.com/questions/4389954/does-openssl-automatically-handle-crls-certificate-revocation-lists-now
   )



X509_STORE *store = getStore();



// Enable CRL checking

X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();

X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK);

X509_STORE_set1_param(store, param);

X509_VERIFY_PARAM_free(param);


I am going to try this out now, but before that , wanted to check with the
community:

   - If the way I am proceeding is correct?
   - Are there any other simpler ways to do this?
   - What would be best approach to follow for CRL checking enabling?
   - Are there any SSL_CTX level APIs for this now?


I am using openssl version openssl-0.9.8r(Also wanted to know if this
behaviour has changed in higher versions of openssl)
Thanks in advance!

Regds,
Ashok

Distinguishing a CA certificate from an end entity certificate Reg.

[Ashok C]

Hi,

What would be the most efficient and easiest way to distinguish a CA
certificate from an actual server/client(end entity) certificate?
We were thinking of identifying the CA with the CA:TRUE constraint from
the text display, but again this check does not cover x509 v1 certificates
where this extension is not present.
Is there any command/openSSL API available which would serve this purpose?

Regds,
Ashok

Re: Distinguishing a CA certificate from an end entity certificate Reg.

[Ashok C]

Thanks Jakob,
We too have the use cases of those four certificates. Now what would be the
best programmatic way to find out for sure if a given certificate is a CA
certificate or not, be it a v3 or a v1.

Regds,
Ashok
 On Feb 24, 2012 12:51 AM, Jakob Bohm jb-open...@wisemo.com wrote:

 On 2/23/2012 10:49 AM, Ashok C wrote:

 Hi,

 What would be the most efficient and easiest way to distinguish a CA
 certificate from an actual server/client(end entity) certificate?
 We were thinking of identifying the CA with the CA:TRUE constraint from
 the text display, but again this check does not cover x509 v1 certificates
 where this extension is not present.
 Is there any command/openSSL API available which would serve this purpose?


 Ah, a classic FAQ.  I think I answered a very similar question
 last year, but here we go again.

 In practice you need to distinguish 4 kinds of certificate:

 1. CA Root.  Recognized by being signed by itself (Subject
 Distinguished Name exactly same as Issuer Distinguished Name),
 by having the CA property not set to FALSE (in other words, it
 is TRUE or absent), by having the similar flags and bits in
 the other usage properties also allowing use as a CA and by
 usually having one of the words ROOT or CA as a word
 substring of its common name (CN in the Subject).  (A word
 substring is a substring bordered on both sides by end/start
 of string or by a non-letter).

 2. Intermediary CA.  Recognized by NOT being signed by itself,
 but still having the various usage properties allowing or not
 preventing use as a CA.

 3. Self-Signed End Entity.  Recognized by being signed by
 itself, but failing one or more of the other checks for being
 a CA root, and/or by having a subject name which is directly
 usable for an end entity (e.g. a domain name or e-mail
 address).  These tend to be created quite sloppily, so the
 only sure test is if someone uses it as an end entity
 certificate.  The next best test is that anything not on
 YOUR list of trusted CA roots is not a CA root until overridden
 by human intervention based on hard offline evidence.

 4. Regular End Entity.  Recognized by NOT being signed by
 itself AND being explicitly marked with one or more attributes
 preventing use as a CA (most professional CA's don't allow end
 entity certificates to act as intermediary CAs, as it would
 completely nullify their identity checking efforts and thus
 the trustworthiness of their root CA cert).

 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 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

Support for certificates other than the X509 standard Reg.

[Ashok C]

Hi,

I understand that X509 is the preferred ITU-T standard for PKI.
But what would be the other certificate standards which are available and
those which a PKI solution needs to support?
First question would be whether there are any certificates which do not
belong to the X509 standard?
Also, what all standards of certificates does the openSSL implementation
support?


Regds,
Ashok

Optional validation of time in OpenSSL Reg.

[Ashok C]

Hi,

I see that the openSSL certificate verify utility uses the
X509_verify_cert() in x509_vfy.c for certificate validation.
Based on the manual pages for verify, I understand that the order for
verification is as follows:

   1. Firstly a certificate chain is built up starting from the supplied
   certificate and ending in the root CA.
   2. The second operation is to check every untrusted certificate's
   extensions for consistency with the supplied purpose.
   3. The third operation is to check the trust settings on the root CA.
   4. The final operation is to check the validity of the certificate
   chain. The validity period is checked against the current system time and
   the notBefore and notAfter dates in the certificate. The certificate
   signatures are also checked at this point.

What would be the best way to make the time check optional?

One way as seen from the code could be to make this call optional based on
some environmental variable.

Eg:

if(TIME_CHECK_ON)

check_cert_time(ctx, xs);

else

don't check time;

Is there any alternative way to achieve this? I understand that by passing
a custom time using

void X509_STORE_CTX_set_time(X509_STORE_CTX *ctx, unsigned long flags,
time_t t);

and by setting this flag --X509_V_FLAG_USE_CHECK_TIME, I can make the
verify code use the time I provide, but whatever time I provide through the
time_t variable, will it be used as notBefore or notAfter time? (since
time_t t represents the number of seconds since the start of the Unix
epoch).

I would need this optional time checking since I cannot count on my system
time to be stable all the time :)

Regds,

Ashok

Re: Question on OpenSSL encryption

[Ashok C]

Hi,

In addition to the online material, are there any good books which we can
refer to understand openSSL better? Both conceptually as well as from the
API/code perspective.
We hear of the Network Security with OpenSSL by John Viega as one good
reference. But it was published in 2002. Any good new books which can be
used?

Regds,
Ashok

On Sat, Jan 7, 2012 at 11:44 PM, Ben Laurie b...@links.org wrote:

 On Sat, Jan 7, 2012 at 4:12 PM, Manish Jain invalid.poin...@gmail.com
 wrote:
 
  Hello Michael/Anyone Else,
 
  Can you be kind enough to please point me to some place/URL where I can
 get
  a bit more information about how the key is negotiated upon ?
 
  I have gone through a a couple of write-ups on OpenSSL which throw light
  upon everything else except for this vital piece of information.

 http://en.wikipedia.org/wiki/Transport_Layer_Security

 
 
  Thanks  Regards
  Manish Jain
 
 
 
  On 07-Jan-12 19:23, Michael S. Zick wrote:
 
  On Sat January 7 2012, Manish Jain wrote:
 
 
  Hi,
 
  I am new to OpenSSL and am trying to prepare some illustrative
  documentation on how it works.
 
  AFAIK, OpenSSL uses the concept of a pair of keys per host : one is a
  private key which is never communicated to any other host, and the
 other
  is a public key which is transmitted to the peer (the other party). The
  client uses the public key of the server (contained in the server's
  certificate) to encrypt its communication, which can only be decrypted
  with the server's private key. Please correct me if I am wrong.
 
 
  That is the essence of what happens and by that the client knows
  that it is communicating with the server it intended to reach
  (authentication).
 
  Now the question is : when the server sends data to the client, what
 key
  does it use for encryption ?
 
 
  The general answer is: The client and server establish a shared key
  for that propose early in the protocol.
 
  Does the client communicate its public key
  to the server (at some initial stage) which the server uses for
  encryption ?
 
 
  If the communications set up between the two requires client
  authentication.
  In many cases the client remains a stranger to the server
  (un-authenticated).
 
  If yes, what if the client does not have a pair of
  public/private keys ?
 
 
  The usual case for public web browsing using https and some other
  protocols.
  The client remains a stranger to the server.
 
  The question arises because it does not seem logical that the server
  would its private key for encrypting data to be sent to the client.
  Else, snoopers who might have picked the public key could decrypt the
  data too.
 
 
  There is an early stage in nearly all protocols, called: key agreement
  where the client and server agree on a key without exchanging any of
  the 'private' information that it is based on.
 
  Any help on clearing up the above points would be greatly appreciated.
 
 
  My comments above are at a very general level.
  If the process was as simple as my answers, OpenSSL would not be as
  large a body of code as it is.  ;-)
 
  Mike
 
 
  Thank you
  Regards
 
  Manish Jain
  invalid.poin...@gmail.com
 
  __
  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
 
  __
  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: Question on OpenSSL encryption

[Ashok C]

Thanks Richard,

What I am looking would be any good book which gives details about SSL
communication like use of certificates, verification of certificates, APIs
to examine certificates, certificate revocation concepts/SSL APIs for that,
etc.

Regds,
Ashok

2012/1/9 Richard Könning richard.koenn...@ts.fujitsu.com

 Am 09.01.2012 13:10, schrieb Ashok C:

  Hi,

 In addition to the online material, are there any good books which we
 can refer to understand openSSL better? Both conceptually as well as
 from the API/code perspective.
 We hear of the Network Security with OpenSSL by John Viega as one good
 reference. But it was published in 2002. Any good new books which can be
 used?


 Well, the questions of the original poster weren't OpenSSL specific, but
 targeted SSL/TLS in general, for this Eric Rescorla's book SSL and TLS:
 Building and Designing Secure Systems is the better book. Sadly being from
 the year 2000 it is somewhat outdated too, but nevertheless a good
 introduction to SSL/TLS. For a description of the OpenSSL API afaik the
 book from Viega et al. is still the most detailed book, despite being
 somewhat outdated.

 For newer versions of TLS (i.e. 1.1 and beyond) one should check newer TLS
 books, e.g. the ones from Joshua Davies or Rolf Oppliger. Until now i had
 none of the two books in my hands so i can't you tell more about the books,
 but maybe a visit at Amazon or similar book traders will give you at least
 a detailed content description.

 Ciao,
 Richard

 __**__**__
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Supporting oldwithold, newwithnew CA certificates Reg.

[Ashok C]

Sorry for spamming, a small correction here.
Scenario 3 is also failing and not successful as indicated in my earlier
email.

*Scenario 3:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection failure.

Regds,
Ashok

On Tue, Dec 27, 2011 at 4:50 PM, Ashok C ash@gmail.com wrote:

 Thanks Dave.
 But regarding this:

 Important note: make sure the old and new root certs have different
 names. (Same for intermediate CAs, which your example doesn't have.)
 OpenSSL looks-up using Issuer name only. It *verifies* AKI if present,
 and of course uses subjectkey to verify child and thus gets an error
 if lookup found wrong parent. But it looks-up only by name, so if
 old and new certs have the same name OpenSSL may use the wrong one.
 


 I actually tested this particular scenario in my testbed and found that it
 is not necessary that the old and new CA certs have different names.
 I generated an oldcacert.pem and and oldcakey.pem using which I signed my
 oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem
 using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem
 had the same subject/issuer names. The scenarios I tested go below:
 *Scenario 1:*
 openssl s_server -cert oldeecert.pem -key oldeekey.pem
 openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
 Result: Connection successful

 *Scenario 2:*
 openssl s_server -cert neweecert.pem -key neweekey.pem
 openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
 Result:Connection successful

 *Scenario 3:*
 openssl s_server -cert neweecert.pem -key neweekey.pem
 openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
 Result: Connection successful
 *
 Scenario 4:*
 openssl s_server -cert oldeecert.pem -key oldeekey.pem
 openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
 Result: Connection Failure

 Now, I put both oldcacert.pem and newcacert.pem into a single
 combined.pem, the first certificate being oldcacert.pem and the second
 certificate being newcacert.pem.

 *Scenario 5:*
 openssl s_server -cert oldeecert.pem -key oldeekey.pem
 openssl s_client -CAfile /root/certs/cacerts/combined.pem
 Result: Connection Successful

 *Scenario 6:*
 openssl s_server -cert neweecert.pem -key neweekey.pem
 openssl s_client -CAfile /root/certs/cacerts/combined.pem
 Result: Connection Successful

 So now, this means that the openSSL verification check does not stop with
 the first matching issuer certificate alone right? Because if that was the
 case, Scenario 6 should have failed.
 I have attached my certificates for reference. All are v3 certificates.
 I am using openssl version openssl-0.9.8g.

 One more clarification:

 If OpenSSL client has cert-and-pkey configured and receives CertReq,
 it sends that cert regardless of any CAlist the server asked for;
 that cert may be accepted or not depending on the server. And if
 callback or engine is used it appears (but I haven't tested) that
 can similarly select any cert regardless of what the server asked.
 


 Are you indicating here that the client can have multiple end entity
 certificates? Till now I had the assumption that the server/client can have
 only a single end entity certificate. Also, if the server can ask client to
 send selective certificates, wouldn't it be applicable that the client also
 can request the server for specific certificates? Are there separate
 openSSL APIs for this or we have to use the same family of
 ssl_ctx_set_client* family of APIs for this purpose also?

 Regds,
 Ashok







 On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson dthomp...@prinpay.comwrote:

From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
Sent: Thursday, 22 December, 2011 10:55

Another doubt I have is about the SSL_CTX_set_client_ca_list
  and the SSL_get_client_ca_list.

I understand that the set method is called by the server to
  set the list of CA names that it actually expects from the client.
  And the client calls ssl_get_client_ca_list to get these names and
  send the appropriate CA certificates in its chain for verification
  to the server.

 Nit: case is important in C identifiers. Skipping that:

 Not quite. Server can call _set_client_CA_list to set the CA names it
 *asks for* from the client; server still uses _load_verify_locations
 to verify the cert received if any. OpenSSL allows you to make these
 different: e.g. ask the client for CA1 and CA2, but verify only CA2,
 or CA2 and CA3, or only CA3. I've never seen a good use for this.

 OpenSSL client calls the client_cert callback or engine only if
 you did *not* set a cert-and-private-key before the handshake.
 Callback or engine can look at the CAlist specified by the server
 if any (see next) to choose what cert-and-private-key to use.
 For callback it apparently needs to call SSL_get_client_CA_list,
 for engine this value

Re: Supporting oldwithold, newwithnew CA certificates Reg.

[Ashok C]

Thanks Dave.
But regarding this:
Important note: make sure the old and new root certs have different
names. (Same for intermediate CAs, which your example doesn't have.)
OpenSSL looks-up using Issuer name only. It *verifies* AKI if present,
and of course uses subjectkey to verify child and thus gets an error
if lookup found wrong parent. But it looks-up only by name, so if
old and new certs have the same name OpenSSL may use the wrong one.



I actually tested this particular scenario in my testbed and found that it
is not necessary that the old and new CA certs have different names.
I generated an oldcacert.pem and and oldcakey.pem using which I signed my
oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem
using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem
had the same subject/issuer names. The scenarios I tested go below:
*Scenario 1:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection successful

*Scenario 2:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
Result:Connection successful

*Scenario 3:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem
Result: Connection successful
*
Scenario 4:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/newcacert.pem
Result: Connection Failure

Now, I put both oldcacert.pem and newcacert.pem into a single combined.pem,
the first certificate being oldcacert.pem and the second certificate being
newcacert.pem.

*Scenario 5:*
openssl s_server -cert oldeecert.pem -key oldeekey.pem
openssl s_client -CAfile /root/certs/cacerts/combined.pem
Result: Connection Successful

*Scenario 6:*
openssl s_server -cert neweecert.pem -key neweekey.pem
openssl s_client -CAfile /root/certs/cacerts/combined.pem
Result: Connection Successful

So now, this means that the openSSL verification check does not stop with
the first matching issuer certificate alone right? Because if that was the
case, Scenario 6 should have failed.
I have attached my certificates for reference. All are v3 certificates.
I am using openssl version openssl-0.9.8g.

One more clarification:
If OpenSSL client has cert-and-pkey configured and receives CertReq,
it sends that cert regardless of any CAlist the server asked for;
that cert may be accepted or not depending on the server. And if
callback or engine is used it appears (but I haven't tested) that
can similarly select any cert regardless of what the server asked.



Are you indicating here that the client can have multiple end entity
certificates? Till now I had the assumption that the server/client can have
only a single end entity certificate. Also, if the server can ask client to
send selective certificates, wouldn't it be applicable that the client also
can request the server for specific certificates? Are there separate
openSSL APIs for this or we have to use the same family of
ssl_ctx_set_client* family of APIs for this purpose also?

Regds,
Ashok






On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson dthomp...@prinpay.comwrote:

From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
Sent: Thursday, 22 December, 2011 10:55

Another doubt I have is about the SSL_CTX_set_client_ca_list
  and the SSL_get_client_ca_list.

I understand that the set method is called by the server to
  set the list of CA names that it actually expects from the client.
  And the client calls ssl_get_client_ca_list to get these names and
  send the appropriate CA certificates in its chain for verification
  to the server.

 Nit: case is important in C identifiers. Skipping that:

 Not quite. Server can call _set_client_CA_list to set the CA names it
 *asks for* from the client; server still uses _load_verify_locations
 to verify the cert received if any. OpenSSL allows you to make these
 different: e.g. ask the client for CA1 and CA2, but verify only CA2,
 or CA2 and CA3, or only CA3. I've never seen a good use for this.

 OpenSSL client calls the client_cert callback or engine only if
 you did *not* set a cert-and-private-key before the handshake.
 Callback or engine can look at the CAlist specified by the server
 if any (see next) to choose what cert-and-private-key to use.
 For callback it apparently needs to call SSL_get_client_CA_list,
 for engine this value is passed separately.

I assume that both these methods are actually optional even when
 SSL_VERIFY_PEER
flag is set to true, i.e., client verifies server and server
 verifies client.

 If OpenSSL server sets VERIFY_PEER but doesn't _set_client_CA_list,
 it sends CertReq with an empty CA list. According to the RFCs
 in this case the client MAY send any certificate of the appropriate
 ClientCertificateType, unless

Re: Supporting oldwithold, newwithnew CA certificates Reg.

[Ashok C]

Thanks Dave. That part of it is clear now.
Another doubt I have is about the SSL_CTX_set_client_ca_list and the
SSL_get_client_ca_list.

I understand that the set method is called by the server to set the list of
CA names that it actually expects from the client. And the client calls
ssl_get_client_ca_list to get these names and send the appropriate CA
certificates in its chain for verification to the server.
I assume that both these methods are actually optional even when
SSL_VERIFY_PEER
flag is set to true, i.e., client verifies server and server verifies
client.

I set up my server and client without these two methods and things still go
fine. What would be the exact purpose of this family of methods? What I
understand from my reading is that the SSL_CTX_set_client_CA_list function
is only needed by server applications that verify the identity of remote
client applications when SSL sessions are started and that if the
SSL_CTX_set_client_CA_list function is not used and you request a client
certificate, the list of CA names that get passed to the client application
are the CAs from the SSL_CTX_load_verify_locations function.

Is my understanding correct?

Regds,
Ashok

On Wed, Dec 21, 2011 at 8:46 AM, Dave Thompson dthomp...@prinpay.comwrote:

From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
Sent: Tuesday, 20 December, 2011 04:16

What will be the recommendation from the open source community for
  supporting the following scenario in a openSSL based client/server
 application:

The certificates involved:
old CA certificate of the CA authority(root)
new CA certificate of the CA authority(root)
Server's end entity certificate issued by the old CA certificate,
  Server's end entity certificate issued by the new CA certificate
Client's end entity certificate issued by the new CA certificate
SSL_VERIFY_PEER set to TRUE. i.e., Client verifies server
 certificate
  and server verifies client certificate.

 Note: in client SSL_VERIFY_PEER fails if server cert doesn't verify;
 in server it requests cert from client, and fails if client cert
 is provided and doesn't verify, but succeeds if client doesn't provide
 cert. To fail in the latter case, add SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
 Or else after the handshake explicitly check SSL_get_peer_certificate
 and if missing do some appropriate error.

 Important note: make sure the old and new root certs have different
 names. (Same for intermediate CAs, which your example doesn't have.)
 OpenSSL looks-up using Issuer name only. It *verifies* AKI if present,
 and of course uses subjectkey to verify child and thus gets an error
 if lookup found wrong parent. But it looks-up only by name, so if
 old and new certs have the same name OpenSSL may use the wrong one.

Scenario:
Now, the client in its SSL_load_verify_locations() will need to
  load both the old CA certificate as well as the new CA certificate.
 snip
So, now it is like loading multiple trust anchors in a single file.
So here, is it better to use the CAFile option to load [] a single
  concatenated PEM file(CAFile)) or is it better to use the CAPath option
  for this scenario: [with hashnames]

 Either. Whichever you or your users prefer.

 Usual caveat: the CApath hash changed between 0.9.8 and 1.0.0.
 Make sure to use the correct one for the code you run.

 Rarer caveat: CApath can be updated while a program using it is
 running; generally this only matters for a (very) long-running
 server. CAfile ignores updates, unless you re-load explicitly.

Basically we wanted to know if CAFile would give a problem
  in case of multiple trust anchor certificates put together?

 No problem; that's quite normal. The truststore, either CAfile
 or CApath or a combination, exists to contain all trusted roots
 and usually (though not always) there are multiple roots.


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Supporting oldwithold, newwithnew CA certificates Reg.

[Ashok C]

Hi,

What will be the recommendation from the open source community for
supporting the following scenario in a openSSL based client/server
application:

*The certificates involved:*
old CA certificate of the CA authority(root)
new CA certificate of the CA authority(root)
Server's end entity certificate issued by the old CA certificate, Server's
end entity certificate issued by the new CA certificate
Client's end entity certificate issued by the new CA certificate
SSL_VERIFY_PEER set to TRUE. i.e., Client verifies server certificate and
server verifies client certificate.

*Scenario:*
Now, the client in its SSL_load_verify_locations() will need to load both
the old CA certificate as well as the new CA certificate. This will be to
make sure that the connection is successful when the server sends the new
end entity certificate or even when the server sends its old EE
certificate(No CRLs involved as of now).

So, now it is like loading multiple trust anchors in a single file.
So here, is it better to use the CAFile option to load the CA certificates
for verification(putting both the old CA certificate + new CA certificate
into a single concatenated PEM file(CAFile)) or is it better to use the
CAPath option for this scenario: Generating hashes for old CA certificate
and new CA certificate separately and putting them into one common
directory(CAPath)?
Basically we wanted to know if CAFile would give a problem in case of
multiple trust anchor certificates put together?


Regds,
Ashok

Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi Dave,

But even with that done/fixed in my test environment I DO get
verify error 24 invalid CA cert depth 1 (my only intermediate).
Is that what you're getting? If so, it looks like maybe the
'purpose' checks have been made stricter since the last time
I did this in test, where I have V1/noextension certs.
I can't set up a test with real(er) (CA)certs immediately.
If you have V1 or otherwise 'substandard' CA certs, you might
try enhancing those.

Yes, I was getting the same error. And after using v3 certificates, the
error did not appear again and my client-server app is working well with
the multi-level configuration. Thanks a lot for your patient help in this
regard.

Regds,
Ashok

On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson dthomp...@prinpay.com wrote:

From: Ashok C [mailto:ash@gmail.com]
Sent: Friday, 02 December, 2011 00:11

Keeping the things you have mentioned in mind, this is how it goes.
In server side, EE key is loaded using
  SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM);
EE certificate is loaded using SSL_CTX_use_certificate_file(ctx,
  eepemfile,SSL_FILETYPE_PEM);
And the intermediate certificate chain is loaded using
  SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain
  contains intermediate CA certs without the rootCA.
In client side, rootCA is loaded using
  SSL_CTX_load_verify_locations(ctx,capemfile,NULL).
After attempting SSL_connect from client, the intermediate
 certificate
  chain and the EE certificate are received in client side using
  SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl)
 respectively.
After this we call SSL_get_verify_result(ssl) which fails.
So question here is that whether we need to add the received
  chain explicitly to the verify locations in client side? Meaning,
  do we need to build the chain from client side explicitly by ourselves?

 First, I made a mistake; it's been a long time since I coded this.
 CTX_use_certificate_chain_file loads BOTH the entity cert (which
 must be first in the file) AND the chain certs, and thus REPLACES
 CTX_use_certificate_file. I'm guessing you have that data,
 since if _use_certificate_chain_ doesn't contain the EE cert
 then handshake can't select this auth type (and we have no other)
 which produces a rather different (and less helpful!) error.

 But even with that done/fixed in my test environment I DO get
 verify error 24 invalid CA cert depth 1 (my only intermediate).
 Is that what you're getting? If so, it looks like maybe the
 'purpose' checks have been made stricter since the last time
 I did this in test, where I have V1/noextension certs.
 I can't set up a test with real(er) (CA)certs immediately.
 If you have V1 or otherwise 'substandard' CA certs, you might
 try enhancing those.

 These specific checks appear to be bypassed for certs in the
 truststore, so putting all of the chain above the server EE
 in the client truststore is an alternative (and works for me).
 In that case the server only needs to send its EE cert (i.e.
 only _use_certificate). This is typically more work to set up
 and manage 'in the wild', but it is an alternative.

Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi Dave,

Keeping the things you have mentioned in mind, this is how it goes.
In server side, EE key is loaded using
SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM);
EE certificate is loaded using SSL_CTX_use_certificate_file(ctx,
eepemfile,SSL_FILETYPE_PEM);
And the intermediate certificate chain is loaded using
SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains
intermediate CA certs without the rootCA.
In client side, rootCA is loaded using
SSL_CTX_load_verify_locations(ctx,capemfile,NULL).
After attempting SSL_connect from client, the intermediate certificate
chain and the EE certificate are received in client side using
SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl)
respectively.
After this we call SSL_get_verify_result(ssl) which fails.
So question here is that whether we need to add the received chain
explicitly to the verify locations in client side? Meaning, do we need to
build the chain from client side explicitly by ourselves?

Regds,
Ashok

On Fri, Dec 2, 2011 at 5:33 AM, Dave Thompson dthomp...@prinpay.com wrote:

From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
Sent: Wednesday, 30 November, 2011 00:51

Some more followup questions here:
  In case of a server application, it is expected to send
 the intermediate certificates to the client. And in this case,
 is this API -- SSL_CTX_load_verify_locations(
) sufficient to be used?
 Or is there a separate API to send the intermediate CA
 certificates
 across to the client?

No, certs to *send* are separate from verifying *received*.

Yes, SSL_CTX_user_certificate_chain_file or
 SSL_CTX_add_extra_chain_cert .

So, in this case certificates to be sent need to sent only
  using the use_certificate* APIs., among which none of them take
  CAPath as an input.

 That's not what I said. _use_certificate[_ASN1|file]
 (but NOT _use_certificate_chain_file) is used to provide
 an entity's own certificate. It is always sent if
 authentication is used for this entity in the handshake
 (for server usually, for client sometimes).

 _use_certificate_chain_file (not 'user', my typo, sorry)
 or _add_extra_chain_cert may be used to specify chain
 or intermediate certs. They are added to the Cert message
 if authentication is used for this entity.

  In this case, how does the s_server/s_client implementation
  work with -CAPath options? Internally does it use just
  load_verify_locations(*,CAPath) ? Or does it translate
  the hashes present in CAPath to X509 objects and then
  use the use_certificate* APIs?

 s_server and s_client call _load_verify_locations, which uses
 CAfile and/or CApath to verify subsequently received cert(s).
 It does NOT use them as own (entity) or chain certs.

To be more clear, is there any option in which we can use
  CAPath to send certificates?

 No. CApath within OpenSSL is only used for verifying received cert(s).

 s_server and s_client do not have any feature to send chain certs.
 They are only test/sample programs; if you want something different,
 use your own program (perhaps based on them, if you wish).

1. I doubt there's a bug in OpenSSL here; this is very widely
used functionality; both CAfile and CApath have worked for me
in all versions I've used. What version(s) are you running,
is it vanilla build or any mods/patches, and built how?

We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64
  environment with few CVE patches.

 I still have 0.9.8g builds (and other 0.9.8) around for support.
 On Solaris/sparc, Linux/x86, and Windows/x86 both CAfile and CApath
 work equivalently and as expected. 1.0.0c also works on all,
 and 1.0.0e on the first two (haven't done 1.0.0e on Windows
 because no longer needed on the systems I support).
 I don't do specific x86_64 builds, we just run x86 code on those
 machines, but I can't imagine this would be an ISA-dependent bug.
 (As opposed to some crypto primitives like AES and SHA1, which do
 have different assembly code -- but are also very well tested.)

 As I asked before, can you reproduce with s_server and s_client?
 If so, post exact files (using a throwaway key) and we can
 try to look at it (although the X509-store/lookup stuff is
 in my opinion among the most confusing part of OpenSSL code).

 If it only occurs in your program(s), I suspect your program(s).
 One idea springs to mind: as I said CAfile is read into memory
 and kept there while CApath is read from disk when needed,
 so maybe something in your program is clobbering memory.
 That's a very common mistake in C (and C++).


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi Dave,

Thanks for the reply.
Some more followup questions here:
  In case of a server application, it is expected to send
 the intermediate certificates to the client. And in this case,
 is this API -- SSL_CTX_load_verify_locations(
) sufficient to be used?
 Or is there a separate API to send the intermediate CA certificates
 across to the client?

No, certs to *send* are separate from verifying *received*.

Yes, SSL_CTX_user_certificate_

 chain_file or SSL_CTX_add_extra_chain_cert .

So, in this case certificates to be sent need to sent only using the
use_certificate* APIs., among which none of them take CAPath as an input.
In this case, how does the s_server/s_client implementation work with
-CAPath options? Internally does it use just
load_verify_locations(*,CAPath) ? Or does it translate the hashes present
in CAPath to X509 objects and then use the use_certificate* APIs?
To be more clear, is there any option in which we can use CAPath to send
certificates?

1. I doubt there's a bug in OpenSSL here; this is very widely
used functionality; both CAfile and CApath have worked for me
in all versions I've used. What version(s) are you running,
is it vanilla build or any mods/patches, and built how?

We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 environment
with few CVE patches.


On Tue, Nov 29, 2011 at 9:51 AM, Dave Thompson dthomp...@prinpay.comwrote:

From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
Sent: Monday, 28 November, 2011 00:35

One more question here:
In case of a server application, it is expected to send
  the intermediate certificates to the client. And in this case,
  is this API -- SSL_CTX_load_verify_locations() sufficient to be used?
  Or is there a separate API to send the intermediate CA certificates
  across to the client?

 No, certs to *send* are separate from verifying *received*.

 Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert .

 Similar but less obvious, if you use client auth (i.e. client
 presents cert) the CA name(s) requested in the CertRequest
 are separate from the CA cert(s) actually used for verification.
 Often you want to make these the same, but it's not automatic.
 Use SSL_[CTX_]set_client_CA_list or SSL_[CTX_]add_client_CA .

P.S. My previous query also is unanswered. It would be great
  if I get some responses to that also ;)

From: Ashok C ash@gmail.com
Date: Wed, Nov 23, 2011 at 12:55 PM

We are implementing multi-layer support for our openssl-based
  PKI solution and had the following query:

 The usual term for what I think you mean is multi-LEVEL CAs,
 or hierarchical CAs.

Currently our PKI solution supports only single layer CA support
  and we use SSL_CTX_load_verify_locations API with the CAFile option,
  meaning that the service loads the CA certificate from a PEM file.
When testing multi-layer support between a client-server model
  with SSL_VERIFY_PEER set to true, we observed that using the CAFile
  (with all CA certificates- root + intermediate concatenated into
  a single PEM file) does not work anymore. But using CAPath option
  (storing each CA in separate file, creating hashes for them in a
  directory and providing that directory in CAPath) seems to work fine.
  Is this a known bug with openSSL or is it something that we are doing
 wrong.

 1. I doubt there's a bug in OpenSSL here; this is very widely
 used functionality; both CAfile and CApath have worked for me
 in all versions I've used. What version(s) are you running,
 is it vanilla build or any mods/patches, and built how?

 2. What exactly are you testing, and what exactly is the error(s)?
 Can you reproduce it with commandline s_client and/or s_server?

 3. For SSL/TLS it is common, but not universal, for the server to
 provide in its handshake all intermediate CA certs, and similarly
 for the client to do so if client-auth is used. If all peers of a
 relier do this it doesn't need to configure any intermediate certs,
 only the root(s). This is often more convenient, since for (some?
 many?) public CAs the intermediates tend to change more often, and
 the entity that gets a cert from the CA may be the first to know.
 You don't say if your 'solution' uses public CAs or your own CA(s);
 if the latter presumably the behavior is more under your control.

 If you are using OpenSSL cert verification (and perhaps other functions)
 for some other protocol/application/whatever, answer may be different.

 4. It's not clear to me if it's standard, but OpenSSL always verifies
 up to a root in the truststore, even if a lower intermediate cert is
 also in the truststore. This is the same for CAfile and/or CApath.

Also, from the openSSL community perspective, is it advisable
  to use CAFile option or CAPath option when providing multi-layer support?

 Maybe. See above about which CA certs to configure.

 If you mean a choice between CAfile and CApath, it's

RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi,

One more question here:
In case of a server application, it is expected to send the intermediate
certificates to the client. And in this case, is this API --
SSL_CTX_load_verify_locations() sufficient to be used? Or is there a
separate API to send the intermediate CA certificates across to the client?
P.S. My previous query also is unanswered. It would be great if I get some
responses to that also ;)

Regds,
Ashok

-- Forwarded message --
From: Ashok C ash@gmail.com
Date: Wed, Nov 23, 2011 at 12:55 PM
Subject: Usage of CAPath/CAFile options in int
SSL_CTX_load_verify_locations Reg.
To: openssl-users@openssl.org


Hi,

We are implementing multi-layer support for our openssl-based PKI solution
and had the following query:

Currently our PKI solution supports only single layer CA support and we use
SSL_CTX_load_verify_locations API with the CAFile option, meaning that the
service loads the CA certificate from a PEM file.
When testing multi-layer support between a client-server model with
*SSL_VERIFY_PEER
*set to true, we observed that using the CAFile(with all CA certificates-
root + intermediate concatenated into a single PEM file) does not work
anymore. But using CAPath option (storing each CA in separate file,
creating hashes for them in a directory and providing that directory in
CAPath) seems to work fine. Is this a known bug with openSSL or is it
something that we are doing wrong.*
*
Also, from the openSSL community perspective, is it advisable to use CAFile
option or CAPath option when providing multi-layer support?



Regds,
Ashok

Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi,

We are implementing multi-layer support for our openssl-based PKI solution
and had the following query:

Currently our PKI solution supports only single layer CA support and we use
SSL_CTX_load_verify_locations API with the CAFile option, meaning that the
service loads the CA certificate from a PEM file.
When testing multi-layer support between a client-server model with
*SSL_VERIFY_PEER
*set to true, we observed that using the CAFile(with all CA certificates-
root + intermediate concatenated into a single PEM file) does not work
anymore. But using CAPath option (storing each CA in separate file,
creating hashes for them in a directory and providing that directory in
CAPath) seems to work fine. Is this a known bug with openSSL or is it
something that we are doing wrong.*
*
Also, from the openSSL community perspective, is it advisable to use CAFile
option or CAPath option when providing multi-layer support?



Regds,
Ashok

How is MD5 fingerprint on X509 created?

[Matt C]

Hello,

I am able to generate an MD5 fingerprint with the following command.

openssl x509 -in user.pem -fingerprint -md5 -noout

This fingerprint matches the fingerprint displayed by Thunderbird/Firefox.

I am trying to generate an MD5 using a hash function in PHP,
http://nl2.php.net/manual/en/function.openssl-digest.php

The results I am getting from the PHP function are not the same as using the
other methods.  I'm sure I'm not putting the right data into the hash
function.

Should I be hashing the entire contents of the PEM file, only part, or is
there additional data I need to add?

Thank you,

Matt

Re: How is MD5 fingerprint on X509 created?

[Matt C]

Thank you Erik and Wim, that's exactly the information I needed!

On Tue, Apr 19, 2011 at 2:27 PM, Wim Lewis w...@omnigroup.com wrote:


 On 19 Apr 2011, at 10:55 AM, Matt C wrote:
  Should I be hashing the entire contents of the PEM file, only part, or is
 there additional data I need to add?

 The fingerprint that openssl computes is the hash of the entire certificate
 in DER format. You should be able to recover the DER-formatted certificate
 by base64-decoding the block of text between the BEGIN/END lines in the
 PEM-formatted certifcate.

 There are other hashes of various parts of the certificate, used for other
 things, but if you're trying to duplicate what openssl -fingerprint is
 doing, that's how.


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Date format for X.509 certificate

[Matt C]

I've extracted a date from a public certificate using the PHP command
openssl_x509_parse.

The date looks like this: 110419141516Z

Can someone tell me how to make sense of this date (in PHP if possible).

Thank you!

Matt

Re: Date format for X.509 certificate

[Matt C]

That's simple.  Thank you again Erik.

On Tue, Apr 19, 2011 at 5:22 PM, Erik Tkal et...@juniper.net wrote:

  110419141516Z = 2011 04(April) 19th 14:15:16Z(UTC)


 
 *Erik Tkal**
 *Juniper OAC/UAC/Pulse Development



 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Matt C
 *Sent:* Tuesday, April 19, 2011 5:19 PM
 *To:* openssl-users@openssl.org
 *Subject:* Date format for X.509 certificate



 I've extracted a date from a public certificate using the PHP command
 openssl_x509_parse.



 The date looks like this: 110419141516Z



 Can someone tell me how to make sense of this date (in PHP if possible).



 Thank you!



 Matt

Optional Verification of Signature and Date..

[Ashok C]

Hi,

I am a newbie user of openssl, and am using openssl C apis to verify
certificates.
Is there any way by which I can ignore the date verificationa and the
signature verification?

Thanks in advance.

Regds,
Ashok

Optional Verification of Signature and Date..

[Ashok C]

Hi,

Does the openssl X509_verify certificate validation API support an argument
that supports skipping of signature and date validation?
Or is there any other way that I can achieve this optional verification.
Please help me out in this regard.

Regds,
Ashok.

API to extract Subject/Issuer Name from X509 certificate

[Ashok C]

Hi,

I was trying to find the correct API for extracting the subject/issuer name
from an x509 certificate using openssl library, but was unable to find the
exact one.
It would be great if someone guides me regarding this.

Thanks in Advance!

Regds,
Ashok

Openssl issue??

[Govind c]

I am trying to to use ftps for secure server. We have two identical 
client trying to connect to the server.Client 1 can connect but not 
client 2. Client 2 throws below error 

error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag 


Openssl on both clients 


openssl-0.9.7a-43.1 
xmlsec1-openssl-1.2.6-3 
openssl-devel-0.9.7a-43.1 


client 1 
--- 


 curl  -3 -v  --ftp-ssl -k -S ftp://abc:xyz...@10.10.10.1 
* About to connect() to 10.10.10.1 port 21 
*   Trying 10.10.10.1... * connected 
* Connected to 10.10.10.1 (10.10.10.1) port 21 
 220 (vsFTPd 2.0.1) 


 AUTH SSL 


 234 Proceed with negotiation. 
* successfully set certificate verify locations: 
*   CAfile: /usr/share/ssl/certs/ca-bundle.crt 
  CApath: none 
* SSL connection using DES-CBC3-SHA 
* Server certificate: 
*subject: /C=US/ST=NJ/L=FP/O=test/CN=test.test.com 
*start date: 2010-03-31 04:53:33 GMT 
*expire date: 2011-03-31 04:53:33 GMT 
*common name: test.test.com (does not match '10.10.10.1') 
*issuer: /C=US/ST=NJ/L=FP/O=test/CN=test.test.com 
* SSL certificate verify result: error number 1 (18), continuing 
anyway. 

 USER abc 


 331 Please specify the password. 

 PASS xyz123 


 530 Login incorrect. 
* the username and/or the password are incorrect 
* Closing connection #0 

client2 


#  curl  -3 -v  --ftp-ssl -k -S ftp://abc:xyz...@10.10.10.1 
* About to connect() to 10.10.10.1 port 21 
*   Trying 10.10.10.1... * connected 
* Connected to 10.10.10.1 (10.10.10.1) port 21 
 220 (vsFTPd 2.0.1) 


 AUTH SSL 


 234 Proceed with negotiation. 
* successfully set certificate verify locations: 
*   CAfile: /usr/share/ssl/certs/ca-bundle.crt 
  CApath: none 
* error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag 
* Closing connection #0 

Cheers 
CG 





  
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Unable to create root certificate in FC7

[Anoop C]

Could anyone tell the procedure to set up the Openssl in fc7..I am using the
certificates for EAP-TLS authentication.

 

What are the packages I need to install?

 

Currently I am using three scripts to generate certificates. I am attaching
it.

 

Thanks in advance.

 

 

 

Regards

Anoop C



From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Anoop C
Sent: Wednesday, November 18, 2009 7:38 PM
To: openssl-users@openssl.org
Subject: Unable to create root certificate in FC7

 

Hi 

 I am getting the following error while generating root certificate. I am
using FC7 with the following openssl packages

 openssl-0.9.6g.tar.gz

 openssl-0.9.7-beta3.tar.gz

 openssl-SNAP-20021027.tar.gz

 

The same was working with RHEL3 and Redhat 4

 

openssl: error while loading shared libraries:
/usr/local/openssl-certgen/lib/libcrypto.so.0.9.7: cannot restore segment
prot after reloc: Permission denied

 

Kindly advice how can I over come the issue

 

 

Regards

Anoop C

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09
07:50:00




CA.clt
Description: Binary data


CA.root
Description: Binary data


CA.svr
Description: Binary data

Unable to create root certificate in FC7

[Anoop C]

Hi 

 I am getting the following error while generating root certificate. I am
using FC7 with the following openssl packages

 openssl-0.9.6g.tar.gz

 openssl-0.9.7-beta3.tar.gz

 openssl-SNAP-20021027.tar.gz

 

The same was working with RHEL3 and Redhat 4

 

openssl: error while loading shared libraries:
/usr/local/openssl-certgen/lib/libcrypto.so.0.9.7: cannot restore segment
prot after reloc: Permission denied

 

Kindly advice how can I over come the issue

 

 

Regards

Anoop C



 




Get your world in your inbox!

Mail, widgets, documents, spreadsheets, organizer and much more with your 
Sifymail WIYI id!
Log on to http://www.sify.com

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to 
Sify Limited and is intended for use only by the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If this is a 
forwarded message, the content of this E-MAIL may not have been sent with 
the authority of the Company. If you are not the intended recipient, an 
agent of the intended recipient or a  person responsible for delivering the 
information to the named recipient,  you are notified that any use, 
distribution, transmission, printing, copying or dissemination of this 
information in any way or in any manner is strictly prohibited. If you have 
received this communication in error, please delete this mail  notify us 
immediately at ad...@sifycorp.com

how to merge multiple public domain certs into one file?

[M C]

Hi...
I've been struggling with how to concatenate multiple public domain certs
into one crt file.

Basically, I have 5 SSL virtual host domains running on 1 apache httpd
server and each host has a separate GeoTrust domain certificate.  Instead of
having 5 individual public *.crt files, is there anyway to merge them
together into 1 file.

Any information would be much appreciated.

Thanks in advance,
Michael

C++ Invoke delegate

[c++newbie]

Hello,

I'd really appreciate if someone can give me an example of how to do this,
I've been spending some time on this without any luck, I'm new to c++ so for
you guys it should be pretty easy.

I'm trying to get the SSL state info and trying to invoke a delegate to pass
the information but I'm not getting any where, here is what I have:

1)  I've created a delegate with the following method:

public __delegate void SSLStateInfo


2) Then inside the following block:

__sealed public __gc class SSLClient : public IDisposable
{

I have added:  

SSLStateInfo* DoSSLStateInfo;


3)  Upon initialization I call the following:

SSL_CTX_set_info_callback(ctx,apps_ssl_info_callback);

4)  At this point I can get the state info in the apps_ssl_info_callback
function but what I would like to do is call the DoSSLStateInfo delegate and
pass it the state info (in the form of a string).


What do I need to do inside the apps_ssl_info_callback function to invoke
the delegate?

I've searched through lots of sites but I can't seem to find a simple
example.

I'd really appreciate the help.

Thanks,
Joseph
-- 
View this message in context: 
http://www.nabble.com/C%2B%2B-Invoke-delegate-tp25636867p25636867.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

MAC address binding to the certificate

[Anoop C]

Hi all

  I am using certificates generated by openssl for authenticating the
WiFi useres using EAP-TLS  802.1x authentication.
  I would like to add MAC address of the user machines into each user
certificates so that the certificates used by one machine cannot be used in
another machine/PC.

Could anyone please help how to create certificate with MAC address
binded to it.

Regards
Anoop



Get your world in your inbox!

Mail, widgets, documents, spreadsheets, organizer and much more with your 
Sifymail WIYI id!
Log on to http://www.sify.com

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to 
Sify Limited and is intended for use only by the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If this is a 
forwarded message, the content of this E-MAIL may not have been sent with 
the authority of the Company. If you are not the intended recipient, an 
agent of the intended recipient or a  person responsible for delivering the 
information to the named recipient,  you are notified that any use, 
distribution, transmission, printing, copying or dissemination of this 
information in any way or in any manner is strictly prohibited. If you have 
received this communication in error, please delete this mail  notify us 
immediately at ad...@sifycorp.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: MAC address binding to the certificate

[Anoop C]

Hi Patrik

   Thanks for the quick response.
I totally agree on your point. Our associates often used to try others
certificate .So I want to remove that threat also by incorporating MAC
address also into the certificates apart from the existing set up.

 Often Wimax CPE vendors used to bind the MAC along with the certificate so
that ones certificate cannot be installed to another CPE.

 I want to remove the risk of certificate stealing. Of course I am usin CRL
for revoking. Still want to know any possibility of adding MAC also to
certificate

Regards
Anoop C
Access Network Engineering
Sify Technologies Ltd.
Chennai
 
Mobile: +91 - 9884015161
Xtn:2867

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Patrick Patterson
Sent: Wednesday, September 09, 2009 5:50 PM
To: openssl-users@openssl.org
Subject: Re: MAC address binding to the certificate

Hi there:

Anoop C wrote:
 Hi all
 
   I am using certificates generated by openssl for authenticating the
 WiFi useres using EAP-TLS  802.1x authentication.
   I would like to add MAC address of the user machines into each user
 certificates so that the certificates used by one machine cannot be used
in
 another machine/PC.
 
 Could anyone please help how to create certificate with MAC address
 binded to it.
 
I think that you may want to revisit your assumptions here - it is
rather trivial to spoof a MAC address, so basing your security on that
is not very good.

Besides, as long as the user has a valid certificate, why do you care
which machine they log in from? If you can't trust the holder of the
certificate to keep it safe, then you have a different set of issues
that MAC address binding will not save you from.

Have fun.

Patrick.

 Regards
 Anoop
 
 
 
 Get your world in your inbox!
 
 Mail, widgets, documents, spreadsheets, organizer and much more with your
Sifymail WIYI id!
 Log on to http://www.sify.com
 
 ** DISCLAIMER **
 Information contained and transmitted by this E-MAIL is proprietary to 
 Sify Limited and is intended for use only by the individual or entity to 
 which it is addressed, and may contain information that is privileged, 
 confidential or exempt from disclosure under applicable law. If this is a 
 forwarded message, the content of this E-MAIL may not have been sent with 
 the authority of the Company. If you are not the intended recipient, an 
 agent of the intended recipient or a  person responsible for delivering
the 
 information to the named recipient,  you are notified that any use, 
 distribution, transmission, printing, copying or dissemination of this 
 information in any way or in any manner is strictly prohibited. If you
have 
 received this communication in error, please delete this mail  notify us 
 immediately at ad...@sifycorp.com
 __
 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
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.409 / Virus Database: 270.13.83/2353 - Release Date: 09/08/09
20:45:00

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Reading DER format public Key Using JSAFE ToolKit

[Dineshkumar C]

Hello Experts,

i am implementing Digital Signature process in our application using the
CRYPTO - J toolkit (JSAFE). i need to read the DER encoded ASN.1 or PEM
format Public Key. Can you please help me to read this file using the JSAFE
tool kit?

Thanks
Dinesh

Re: 3des and plain-encrypted size

[José Hidalgo C .]

Thanks!!! I solved with EVP_CIPHER_CTX_set_padding(ctx,0), and padding the
string manually

On Sun, Apr 5, 2009 at 8:07 AM, Ger Hobbelt g...@hobbelt.com wrote:

 This has to do with padding, which is at least 1 byte, and always
 ensures input + padding is an integer multiple of the block size.
 Hence 8 input + 1 byte minimum padding == 8 bytes input + 8 bytes padding.

 See what happens when you feed it, for instance, 5 bytes of input:
 resulting file should be 8 bytes (des3 blocksize = 8)


 2009/4/3 José Hidalgo C. jhidal...@gmail.com:
  Hi:
 
  I'm using the openssl and EVP_EncryptInit_ex, EVP_EncryptUpdate,
  EVP_EncryptFinal_ex sequence to encrypt a a short message with 3des-cbc,
 but
  i get an strange  problem. I expect if the data size is 8 bytes, the
  encrypted data lenght is 8 bytes too, but i get 16 bytes. If the data
 size
  is 16 bytes, the encrypted data length is 24 bytes. I'm sure that the
 data
  size is 8 bytes, or 16 bytes, but i never get the expeted results,
 somebody
  know why?
  The command used in openssl:
 
  openssl des3 -iv 1234567812345678 -K
  0123456789ABCDEFFEDCBA98765432100123456789ABCDEF  -in claro.txt -out
  claro.bin
 
  ls -l show 8 bytes in claro.txt, and 16 bytes in claro.bin
 
  When i use the EVP_EncryptUpdate function, the strlen show 8 bytes in the
  text message.
 
  Thanks.
 
 
  --
  --
  José Hidalgo C.
  Ingeniero de Software
  Akzio Consultores - http://www.akzio.cl
  Huérfanos 669 of. 609 - Santiago
  Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088
 



 --
 Met vriendelijke groeten / Best regards,

 Ger Hobbelt

 --
 web:http://www.hobbelt.com/
http://www.hebbut.net/
 mail:   g...@hobbelt.com
 mobile: +31-6-11 120 978
 --
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org




-- 
--
José Hidalgo C.
Ingeniero de Software
Akzio Consultores - http://www.akzio.cl
Huérfanos 669 of. 609 - Santiago
Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088

3des and plain-encrypted size

[José Hidalgo C .]

Hi:

I'm using the openssl and EVP_EncryptInit_ex, EVP_EncryptUpdate,
EVP_EncryptFinal_ex sequence to encrypt a a short message with 3des-cbc, but
i get an strange  problem. I expect if the data size is 8 bytes, the
encrypted data lenght is 8 bytes too, but i get 16 bytes. If the data size
is 16 bytes, the encrypted data length is 24 bytes. I'm sure that the data
size is 8 bytes, or 16 bytes, but i never get the expeted results, somebody
know why?
The command used in openssl:

openssl des3 -iv 1234567812345678 -K
0123456789ABCDEFFEDCBA98765432100123456789ABCDEF  -in claro.txt -out
claro.bin

ls -l show 8 bytes in claro.txt, and 16 bytes in claro.bin

When i use the EVP_EncryptUpdate function, the strlen show 8 bytes in the
text message.

Thanks.


-- 
--
José Hidalgo C.
Ingeniero de Software
Akzio Consultores - http://www.akzio.cl
Huérfanos 669 of. 609 - Santiago
Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088

len of encrypted data

[José Hidalgo C .]

Hi... a simple question, i hope somebody know the solution:

I need to use the EVP_DecryptUpdate... but for fifth argument, i need the
large of encrypted.. how i do this? i'm sure that strlen not works...

Thanks!!!

EVP_DecryptFinal_ex:bad decrypt

[José Hidalgo C .]

Hi  i'm having problems with the function EVP_DecryptFinal_ex... i have
the next code:

#include stdio.h
#include string.h
#include libgen.h
#include wchar.h
#include sys/time.h
#include openssl/pem.h
#include openssl/sha.h
#include openssl/hmac.h
#include openssl/evp.h
#include openssl/bio.h
#include openssl/buffer.h
#include openssl/err.h

#define LEN_KEY 16
#define ENC_SIZE 512000
#define MSG_SIZE 512000
#define ENCRIPTA 1
#define DESENCRIPTA 0

void unbase64(unsigned char *input, char **ret, int *blen){
  BIO *b64, *bmem;
  char *buff,*tmp;
  int length;

  length = strlen(input)+1;
  tmp = malloc(length*sizeof(char));
  strcpy(tmp,input);
  strcat(tmp,\n\0);

  buff = (char *)malloc(length);
  memset(buff, 0, length);

  b64 = BIO_new(BIO_f_base64());
  bmem = BIO_new_mem_buf(tmp, length);
  bmem = BIO_push(b64, bmem);

  *blen = BIO_read(bmem, buff, length);
  BIO_free_all(bmem);

  strcpy(*ret,buff);

  free(tmp);
  free(buff);
}

void base64(const unsigned char *input, int length, char **ret){
  BIO *bmem, *b64;
  BUF_MEM *bptr;
  char *buff;

  b64 = BIO_new(BIO_f_base64());
  bmem = BIO_new(BIO_s_mem());
  b64 = BIO_push(b64, bmem);

  BIO_write(b64, input, length);
  BIO_flush(b64);
  BIO_get_mem_ptr(b64, bptr);

  buff = (char *)malloc(bptr-length);
  memcpy(buff, bptr-data, bptr-length-1);
  buff[bptr-length-1] = 0;

  BIO_free_all(b64);

  strcpy(*ret,buff);

}

void rpad(const char *to_pad, char **padded, char *pad_char , int len){
int i,start;

start = strlen(to_pad);
strcpy(*padded,to_pad);
for(i = start; i = len; i++) {
strcat(*padded,pad_char);
}
}

void lpad(const char *to_pad, char **padded, char *pad_char , int len){
int i,start;

start = strlen(to_pad);
strcpy(*padded,);
for(i = start; i = len; i++) {
strcat(*padded,pad_char);
}
strcat(*padded,to_pad);
}

void hextoascii(const char *hex, char **ascii){
int i;
char *tmp;

tmp = malloc(2*sizeof(char ));
strcpy(*ascii,);


for(i=0; i  strlen(hex) ; i=i+2){
sprintf(tmp,%c%c,*(hex+i),*(hex+i+1));
sprintf(tmp,%c,(unsigned int)strtol(tmp,NULL,16));
strcat(*ascii,tmp);
}

free(tmp);
}

void asciitohex(const char *ascii, char **hex){
int i;
char *tmp;

tmp = malloc(2*sizeof(char ));
strcpy(*hex,);

for(i=0; i  strlen(ascii) ; i++){
sprintf(tmp,%02X,*(ascii+i)255);
strcat(*hex,tmp);
}

free(tmp);
}

void tripledes(char *llave1, char *llave2, char *text, char **ret, int
action) {
EVP_CIPHER_CTX ctx;
unsigned char iv[] = OTRACLAV;
char *key,*key1,*key2,*encrypted,*encryptedbase64,*plain;
int olen, tlen, encrypted_len,flen;
FILE *fdcypher;

key = malloc(24*sizeof(char ));
key1 = malloc(8*sizeof(char ));
key2 = malloc(8*sizeof(char ));
encryptedbase64 = malloc(ENC_SIZE*sizeof(char ));
plain = malloc(MSG_SIZE*sizeof(char ));
encrypted = malloc(ENC_SIZE*sizeof(char ));

hextoascii(llave1,key1);
hextoascii(llave2,key2);

strcpy(key,key1);
strcat(key,key2);
strcat(key,key1);

EVP_CIPHER_CTX_init(ctx);

switch(action) {
  case ENCRIPTA:
bzero(encrypted, ENC_SIZE);
EVP_EncryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, key, iv);
EVP_EncryptUpdate(ctx, encrypted, olen, text, strlen(text));
EVP_EncryptFinal_ex(ctx, encrypted + olen, tlen);
EVP_CIPHER_CTX_cleanup(ctx);
encrypted_len = olen + tlen;
base64(encrypted,encrypted_len,encryptedbase64);
strcpy(*ret,encryptedbase64);
break;
  case DESENCRIPTA:
bzero(plain, ENC_SIZE);
fdcypher = fopen(text,r);
fseek(fdcypher, 0L, SEEK_END);
flen = ftell(fdcypher);
rewind(fdcypher);
fread(encryptedbase64,flen,1,fdcypher);

unbase64(encryptedbase64, encrypted, encrypted_len);

EVP_DecryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, key, iv);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}

fprintf(stderr,%d - %d\n,strlen(encrypted),encrypted_len);
EVP_DecryptUpdate(ctx, plain, olen, encrypted, encrypted_len);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}

EVP_DecryptFinal_ex(ctx, plain + olen, tlen);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}

EVP_CIPHER_CTX_cleanup(ctx);
encrypted_len = olen + tlen;
strncpy(*ret,plain,encrypted_len);

break;
}


free(key);
}


int main(int argc, char **argv ){
char *llave1,*llave2,*messge,*res;
int action;

llave1 = malloc(LEN_KEY);
llave2 = malloc(LEN_KEY);
messge = malloc(MSG_SIZE);
res = malloc(ENC_SIZE);

action

Re: clear text vs opaque signature

[Jan C.]

Hi,
ok, so the clear text signature general form is something like:


--A3DB62BE42E8E4D7716813FA55957190

My Signed Text

--A3DB62BE42E8E4D7716813FA55957190
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIIFlgYJKoZIhvcNAQcCoIIFhzCCBYMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
...

--A3DB62BE42E8E4D7716813FA55957190--



And the opaque is the same thing but entirely encoded en B64 and
attached to the email as attachment ? Is that correct ?

Regards,
Jan



On Wed, Feb 11, 2009 at 4:42 PM, Dr. Stephen Henson st...@openssl.org wrote:
 On Wed, Feb 11, 2009, Jan C. wrote:

 Hello everybody,
 I would like to ask what is the difference, from the cryptographic
 point of view, between an opaque signature (-nodetach) and a clear
 text signature.


 No cryptographic difference at all: they are different ways of packaging the
 same thing.

 In practical terms the cleartext multipart/mime version can sometimes be
 corrupted by mail gateways whereas the embedded signature form is more
 resistant.

 The embedded form in MIME messages is often base64 encoded which will increase
 its size.

 Current versions of OpenSSL can only verify embedded signatures if the whole
 content is in memory. Version 0.9.9 can generate embedded signatures on the
 fly though.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
 OpenSSL project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 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: clear text vs opaque signature

[Jan C.]

On Thu, Feb 12, 2009 at 12:46 PM, Dr. Stephen Henson st...@openssl.org wrote:
 On Thu, Feb 12, 2009, Jan C. wrote:

 Hi,
 ok, so the clear text signature general form is something like:


 --A3DB62BE42E8E4D7716813FA55957190

 My Signed Text

 --A3DB62BE42E8E4D7716813FA55957190
 Content-Type: application/x-pkcs7-signature; name=smime.p7s
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename=smime.p7s

 MIIFlgYJKoZIhvcNAQcCoIIFhzCCBYMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
 ...

 --A3DB62BE42E8E4D7716813FA55957190--



 And the opaque is the same thing but entirely encoded en B64 and
 attached to the email as attachment ? Is that correct ?


 Cleartext would have MIME headers in the first part.

 Opaque includes the content in the signature structure so you only get one
 part.

Ok


 If you want to see what they look like generate a few with the smime utility.

That's what I did but I wanted to understand the generated format ;)

Thanks,
Jan


 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
 OpenSSL project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 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

clear text vs opaque signature

[Jan C.]

Hello everybody,
I would like to ask what is the difference, from the cryptographic
point of view, between an opaque signature (-nodetach) and a clear
text signature.

Thanks in advance for your answers,
Jan.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Certificates on embedded systems without filesystems

[Bhagvan C]

I see these in ssl.h

int SSL_CTX_use_certificate(SSL_CTX *ctx, X509 *x);
int SSL_CTX_use_certificate_ASN1(SSL_CTX *ctx, int len, unsigned char *d);

and I've used the SSL_CTX_use_certificate_ASN1(), with 'd'
being a DER encoded cert in a buffer

Bhagvan

David Schwartz [EMAIL PROTECTED] wrote: 
 i mean is there any equivalent function for
 SSL_CTX_use_certificate_chain_file which takes certificate buffer
 instead of certificate file name.

Just look at the source code to SSL_CTX_use_certificate_chain_file. As I
recall (it has been awhile) you will find code in there that address the
certificates from the file one-by-one. Just follow the same pattern getting
the certificates from wherever.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


   
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

RE: 'make test' error - I am unable to access the ./demoCA/newcerts directory

[C K KIRAN-KNTX36]

Hi,
Check if the directory exists openssl-0.9.8g/apps/demoCA.
Its trying to run the the demo certification authority test i guess. It looks 
like its not able to find the directory path or some thing like that. First of 
all do u want to run the the test case.
Regards,
Kiran
 



From: [EMAIL PROTECTED] on behalf of Sisyphus
Sent: Tue 22-Jan-2008 5:23 PM
To: openssl-users@openssl.org
Subject: Re: 'make test' error - I am unable to access the ./demoCA/newcerts 
directory




- Original Message -
From: C K KIRAN-KNTX36 [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Tuesday, January 22, 2008 7:27 PM
Subject: RE: 'make test' error - I am unable to access the
./demoCA/newcerts directory


Try just touching those directories. Hopefully that should fix your problem.
The problem i guess here is that, your make is running
some test cases to generate some kind of certificates and its failing.
Regards,
Kiran
---

I ran:
-
[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g
$ touch test

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g
$ cd test

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g/test
$ touch demoCA

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g/test
$ cd demoCA

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g/test/demoCA
$ touch newcerts

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g/test/demoCA
$ cd ../..

[EMAIL PROTECTED] /c/_32/comp/openssl-0.9.8g
-

I'm not all that familiar with 'touch' - but I guess that's what you meant
for me to do.

However, when I re-run 'make test' I get the same error.

Just prior to the error quoted in the subject line of this thread I get:

--
Loading 'screen' into random state -./demoCA/newcerts: Invalid argument
 done
--

Could it be that the real cause of the problem is that Invalid argument ?

Cheers,
Rob

__
OpenSSL Project http://www.openssl.org 
http://www.openssl.org/ 
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


winmail.dat

RE: EC_KEY_new_by_curve_name fails when I use NID_secp112r1, NID_secp112r2, NID_secp128r1, NID_secp128r2 etc

[C K KIRAN-KNTX36]

Hi Alex,
It looks like, you are using NID value in the place of curve name.
Please verify once. 
Regards,
Kiran

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-openssl-
 [EMAIL PROTECTED] On Behalf Of Alex Pokotilo
 Sent: Monday, October 01, 2007 1:09 PM
 To: openssl-users@openssl.org
 Subject: EC_KEY_new_by_curve_name fails when I use NID_secp112r1,
 NID_secp112r2, NID_secp128r1, NID_secp128r2 etc
 
 Fail occurs because EC_GROUP_set_curve_GFp calls
 ec_GFp_nist_group_set_curve and since we are not working with 192,
 224, 256, 384, 521 fields.
 Why the function is restricted to work with following fields ? Is it
 for security considerations ?
 
 Regards,
 Alex
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: EC_KEY_new_by_curve_name fails when I use NID_secp112r1, NID_secp112r2, NID_secp128r1, NID_secp128r2 etc

[C K KIRAN-KNTX36]

Hi Alex,
Please ignore the below mail.
It looks like, the issue is with the recommended elliptic curves, should
have a property where the degree of the curve is  160. So all the
curves with curve degree  160 will be rejected. You should be able to
bypass the condition if you want to use the above curves only.
Regards,
Kiran


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-openssl-
 [EMAIL PROTECTED] On Behalf Of C K KIRAN-KNTX36
 Sent: Monday, October 01, 2007 1:55 PM
 To: openssl-users@openssl.org
 Subject: RE: EC_KEY_new_by_curve_name fails when I use NID_secp112r1,
 NID_secp112r2, NID_secp128r1, NID_secp128r2 etc
 
 Hi Alex,
 It looks like, you are using NID value in the place of curve name.
 Please verify once.
 Regards,
 Kiran
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:owner-openssl-
  [EMAIL PROTECTED] On Behalf Of Alex Pokotilo
  Sent: Monday, October 01, 2007 1:09 PM
  To: openssl-users@openssl.org
  Subject: EC_KEY_new_by_curve_name fails when I use NID_secp112r1,
  NID_secp112r2, NID_secp128r1, NID_secp128r2 etc
 
  Fail occurs because EC_GROUP_set_curve_GFp calls
  ec_GFp_nist_group_set_curve and since we are not working with 192,
  224, 256, 384, 521 fields.
  Why the function is restricted to work with following fields ? Is it
  for security considerations ?
 
  Regards,
  Alex
 
__
  OpenSSL Project
http://www.openssl.org
  User Support Mailing List
openssl-users@openssl.org
  Automated List Manager
[EMAIL PROTECTED]
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Fwd: openssl ECC/ECDSA question

[C K KIRAN-KNTX36]

Hello,
1)
  Give the above constraints which of the curve definitions in
  crypto/curve/ec_curve.c would fit within my requirements?
Have a look at the below link if you have the acess.

http://grouper.ieee.org/groups/1363/Research/Other.html#ANSI

2)What are the functions/APIs I can use to get the order of
  the base point n - would it be EC_GROUP_get_degree()? 

You can use EC_GROUP_get_order. Have a look at ec_lib.c.
In GF(2^m), m is the degree of the polynomial field. Where m is a
positive integer. You can use EC_GROUP_get_degree, to get the value of
m.
Regards,
Kiran   



 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-openssl-
 [EMAIL PROTECTED] On Behalf Of Marek Marcola
 Sent: Friday, August 17, 2007 4:28 AM
 To: Anand Giriraj
 Cc: openssl-users@openssl.org
 Subject: Re: Fwd: openssl ECC/ECDSA question
 
 Hello,
 
  I have tried sending the following email to
openssl-users@openssl.org
  after subscribing to the list but somehow my emails dont seem to be
  reaching anyone. I was wondering if you could help with the
questions
  below, or send it to the list on my behalf and CC me. I really
  appreciate your help as I am somewhat stuck with out this help.
 
  thanks
  -AG
 
  -- Forwarded message --
  From: Anand Giriraj [EMAIL PROTECTED]
  Date: Aug 16, 2007 8:51 AM
  Subject: Re: openssl ECC/ECDSA question
  To: openssl-users@openssl.org
 
  Sending this again, as I think the message didnt reach last time..
 
 
  On 8/15/07, Anand Giriraj [EMAIL PROTECTED]  wrote:
 
 
  Hi,
 
 
  I had a question with regards to the openssl 0.9.8e
ECC/ECDSA
  implementation. I would appreciate your quick response on
  this. Please include me in all replies as I am not yet
  subscribed to the list.
 
  Thanks
  -AG
 
  The FIPS document indicates the following statement:
 
  The FIPS-validated cryptomodule shall implement ECDSA where
  the order of the base point is a [assignment: size of the
  order of the base point n in number of bits that is 256 or
  greater]-bit value, and where the algorithm conforms with
ANSI
  X9.62-1998, Public Key Cryptography for the Financial
Services
  Industry: The Elliptic Curve Digital Signature Algorithm
  (ECDSA). 
 
  In addition to the above, there is a requirement to have all
  the domain parameters be for curves only over GF(p) and
  GF(2^m).
 
  1)
  Give the above constraints which of the curve definitions in
  crypto/curve/ec_curve.c would fit within my requirements?
 You may list all supported curves with command:
  $ openssl ecparam -list_curves
 I think that curves over GF(p):
secp256k1
secp384r1
secp521r1
prime256v1
 and curves over GF(2^m):
   sect283k1
   sect283r1
   sect409k1
   sect409r1
   sect571k1
   sect571r1
 have order of base point G greater then 256bits
 
  2) What are the functions/APIs I can use to get the order of
  the base point n - would it be EC_GROUP_get_degree()?
 Order of base point G is prime number n (p specifies finite field),
 in OpenSSL name scheme (EC_GROUP structure) this means:
   G - generator
   n - order
   p - field
 but EC_GROUP_get_degree() functions returns number of bits of filed,
 I'm not sure - maybe this should be number of bits of order ?
 Or EC_GROUP_get_degree() means something else.
 
 Best regards,
 --
 Marek Marcola [EMAIL PROTECTED]
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Verisign Certificate

[C K KIRAN-KNTX36]

Hi,

Please try this...sorry for late responsethis is straight forward
thing.

openssl x509 -inform DER -in cert.der -outform PEM -out cert.pem

openssl x509 -inform PEM -in cert.pem -text -noout

Regards,

Kiran

 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kaushal Shriyan
Sent: Tuesday, August 07, 2007 11:14 PM
To: openssl-users@openssl.org
Subject: Re: Verisign Certificate

 

Hi Kiran

Now the verisign has given me the certificate as SSL.der format so can
you please provide me the working example using openssl to convert it
into SSL.pem
format taking my file SSL.der in question

Thanks again 

Sorry for the trouble

Thanks and Regards

Kaushal






On 8/6/07, C K KIRAN-KNTX36  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]  wrote:

Hi,

You should have received the certificate in PEM or DER format. No need
to save the file .txt format.

Do openssl -inform whichever form PEM or DER -in file.(der or pem)
-noout -text 

This will dump the text form of the certificate.

Regards,

Kiran

 

 



From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
] On Behalf Of Kaushal Shriyan
Sent: Monday, August 06, 2007 7:23 PM
To: openssl-users@openssl.org
Subject: Verisign Certificate

 

Hi,

I have received certificate from Verisign in the email. 

I have copied it to a notepad and saved it as abc.txt

I am running the command 

openssl x509 -in abc.txt -out ssl.pem

is this the right command

Thanks and Regards

Kaushal

 

RE: Verisign Certificate

[C K KIRAN-KNTX36]

Hi,

You should have received the certificate in PEM or DER format. No need
to save the file .txt format.

Do openssl -inform whichever form PEM or DER -in file.(der or pem)
-noout -text 

This will dump the text form of the certificate.

Regards,

Kiran

 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kaushal Shriyan
Sent: Monday, August 06, 2007 7:23 PM
To: openssl-users@openssl.org
Subject: Verisign Certificate

 

Hi,

I have received certificate from Verisign in the email. 

I have copied it to a notepad and saved it as abc.txt

I am running the command 

openssl x509 -in abc.txt -out ssl.pem

is this the right command

Thanks and Regards

Kaushal

EC

[C K KIRAN-KNTX36]

Hi All,
I am using elliptic curves. And, I am setting the value of private key
filed in EC_KEY structure before calling EC_KEY_generate_key. Every time
I am getting different values of the public key.
I need a help. In,
W=sG. 
Where,
W is the public key
S is the private key and 
G is the base point.
Is it possible to have different values for W given the same value of s
and G. It seems to be little absurd but I am getting different values.
Can anyone clarify my doubt? Thanks is advance

Regards,
Kiran


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

ECDSA

[C K KIRAN-KNTX36]

Hi All,
I am using ECDSA with 224 bit secp224r1 curve. But the signature I am
getting is of size 64bytes; shouldn't it be 56 bytes (r||s)? Also its
not 56bytes + 8bytes zero's padding. Please help me.
Thanks,
Kiran

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

EC

[C K KIRAN-KNTX36]

Hi All, 

I am trying the below commands what is going wrong,

 

[EMAIL PROTECTED] crypt]$ openssl ecparam -outform DER -out ec-key.pem
-name secp224r1 -genkey

[EMAIL PROTECTED] crypt]$ openssl ec -inform DER -in ec-key.der -text
-noout

read EC key

unable to load Key

19331:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:tasn_dec.c:1294:

19331:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:tasn_dec.c:380:Type=EC_PRIVATEKEY

19331:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC
lib:ec_asn1.c:1116:

 

Regards,

Kiran

 

RE: EC

[C K KIRAN-KNTX36]

That's a typo error
[EMAIL PROTECTED] crypt]$ openssl ecparam -outform DER -out ec-key.der -name 
secp224r1 -genkey
[EMAIL PROTECTED] crypt]$ openssl ec -inform DER -in ec-key.der -text -noout
read EC key
unable to load Key
19387:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:tasn_dec.c:1294:
19387:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
error:tasn_dec.c:380:Type=EC_PRIVATEKEY
19387:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC 
lib:ec_asn1.c:1116:
[EMAIL PROTECTED] crypt]$

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Florian MANACH
Sent: Friday, July 06, 2007 3:18 PM
To: openssl-users@openssl.org
Subject: Re: EC

Here is the part that seems to be wrong

-outform DER -out ec-key.pem
-inform DER -in ec-key.der

Try with the same filename in both commands.

-- 
Florian Manach
NUMLOG
[EMAIL PROTECTED]
(+33)0130791616

C K KIRAN-KNTX36 a écrit :
 Hi All,
 
 I am trying the below commands what is going wrong,
 
  
 
 [EMAIL PROTECTED] crypt]$ openssl ecparam -outform DER -out ec-key.pem 
 -name secp224r1 -genkey
 
 [EMAIL PROTECTED] crypt]$ openssl ec -inform DER -in ec-key.der -text -noout
 
 read EC key
 
 unable to load Key
 
 19331:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
 tag:tasn_dec.c:1294:
 
 19331:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
 error:tasn_dec.c:380:Type=EC_PRIVATEKEY
 
 19331:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC 
 lib:ec_asn1.c:1116:
 
  
 
 Regards,
 
 Kiran
 
  
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]