Re: Q: creating CSR for encryption-only cert?

[Mark Hack]

Yes I used the PQ openssl based on liboqs
Since you were not specific on what the use case, and I was not certain
why you wanted a Kyber Public/Private key pair when other algorithms
are better suited to PQ authentication, I supplied the TLS example.
Regards
Mark Hack


On Mon, 2022-10-03 at 21:08 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Thank you - and it’s great to see that 100% PQ Key Exchange is
> working with the existing code (I assume - based on liboqs?). 
> But generating signature is not acceptable in my use case, which is
> why we settled on a KEMTLS-like approach. Or, conceptually, like
> MQV/HMQV. Authenticating the peer implicitly by having its long-term
> (certified) public key participating in the Key Exchange. 
> I fully realize that the current TLS-1.3 does not support this kind
> of Key Exchange. Which is fine, because we’re not using TLS. :-)
> 
> Thanks
> 
> Regards,Uri
> > On Oct 3, 2022, at 17:02, Mark Hack  wrote:
> > 
> > 
> > @font-face { font-family: "Cambria Math"; }
> > @font-face { font-family: Calibri; }
> > @font-face { font-family: "Andale Mono"; }
> > p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size:
> > 11pt; font-family: Calibri, sans-serif; }
> > span.EmailStyle17 { font-family: Calibri, sans-serif; color:
> > windowtext; }
> > .MsoChpDefault { font-family: Calibri, sans-serif; }
> > @page WordSection1 { size: 8.5in 11in; margin: 1in; }
> > div.WordSection1 { page: WordSection1; }In this case you need to
> > look at certificate / signature generation separately from the key
> > exchange.  In classical terms, I can have anRSA key with a RSA-
> > SHA256 signature and use DHE elliptic curves to exchange a secret
> > without knowing the elliptic curve public private key pair.
> > For example to use Dilthium public/private keys and a Dilithium
> > signature , you can use the following to generate a csr ( or self
> > sign):
> > openssl req -new -newkey dilithium2  -keyout qsc.key -config
> > openssl.cnf -nodes 
> > 
> > After you have the signed certificate, TLS uses that certificate
> > but specifies Kyber for the key exchanges.
> > I self signed a dilithium certificate and started a server
> > using:openssl s_server -cert  dilithium.crt -key dilithium.key
> > -groups kyber768 
> > 
> > Then connected with a client using:openssl s_client -connect
> > 127.0.0.1:4433  -groups kyber768
> > This return a good connection:
> > No client certificate CA names sentPeer signature type:
> > Dilithium2Server Temp Key: kyber768---SSL handshake has read 7911
> > bytes and written 1589 bytesVerification error: self signed
> > certificate---New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384Server
> > public key is 10496 bit
> > 
> > RegardsMark Hack
> > 
> > 
> > On Mon, 2022-10-03 at 15:11 +, Blumenthal, Uri - 0553 - MITLL
> > wrote:
> > > TLDR; 
> > > Need to create a CSR for a key pair whose algorithm does not
> > > allow signing (either because it’s something like Kyber, or
> > > because restriction enforced by HSM). How to do it?
> > >  
> > > There are several use cases that require certifying long-term
> > > asymmetric keys that are only capable of encryption/decryption –
> > > but not signing/verification. That could be either because the
> > > algorithm itself does not do signing, or because the private key
> > > is generated and kept in a secure hardware that enforces usage
> > > restriction.
> > >  
> > > CSR is supposed to be signed by the corresponding private key to
> > > prove possession. Obviously, it cannot be done with a key such as
> > > described above. How is this problem addressed in the real world?
> > >  With AuthKEM and KEMTLS, how would these protocols get their
> > > certificates?
> > >  
> > > Thanks!
> > > --
> > > V/R,
> > > Uri Blumenthal  Voice: (781) 981-
> > > 1638 
> > > Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
> > > MIT Lincoln Laboratory  
> > > 244 Wood Street, Lexington, MA  02420-9108  
> > >  
> > > Web: https://www.ll.mit.edu/biographies/uri-blumenthal
> > > Root CA: https://www.ll.mit.edu/llrca2.pem
> > >  
> > > There are two ways to design a system. One is to make it so
> > > simple there are obviously no deficiencies.
> > > The other is to make it so complex there are no obvious
> > > deficiencies.
> > >  
> > >  
> > >   -  C. A. R.
> > > Hoare
> > >  

Re: Q: creating CSR for encryption-only cert?

[Mark Hack]

In this case you need to look at certificate / signature generation
separately from the key exchange.  In classical terms, I can have anRSA
key with a RSA-SHA256 signature and use DHE elliptic curves to exchange
a secret without knowing the elliptic curve public private key pair.
For example to use Dilthium public/private keys and a Dilithium
signature , you can use the following to generate a csr ( or self
sign):
openssl req -new -newkey dilithium2  -keyout qsc.key -config
openssl.cnf -nodes 

After you have the signed certificate, TLS uses that certificate but
specifies Kyber for the key exchanges.
I self signed a dilithium certificate and started a server
using:openssl s_server -cert  dilithium.crt -key dilithium.key -groups
kyber768 

Then connected with a client using:openssl s_client -connect
127.0.0.1:4433  -groups kyber768
This return a good connection:
No client certificate CA names sentPeer signature type:
Dilithium2Server Temp Key: kyber768---SSL handshake has read 7911 bytes
and written 1589 bytesVerification error: self signed certificate---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384Server public key is
10496 bit

RegardsMark Hack


On Mon, 2022-10-03 at 15:11 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> TLDR; 
> Need to create a CSR for a key pair whose algorithm does not allow
> signing (either because it’s something like Kyber, or because
> restriction enforced by HSM). How to do it?
>  
> There are several use cases that require certifying long-term
> asymmetric keys that are only capable of encryption/decryption – but
> not signing/verification. That could be either because the algorithm
> itself does not do signing, or because the private key is generated
> and kept in a secure hardware that enforces usage restriction.
>  
> CSR is supposed to be signed by the corresponding private key to
> prove possession. Obviously, it cannot be done with a key such as
> described above. How is this problem addressed in the real world?
>  With AuthKEM and KEMTLS, how would these protocols get their
> certificates?
>  
> Thanks!
> --
> V/R,
> Uri Blumenthal  Voice: (781) 981-1638 
> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
> MIT Lincoln Laboratory  
> 244 Wood Street, Lexington, MA  02420-9108  
>  
> Web: https://www.ll.mit.edu/biographies/uri-blumenthal
> Root CA: https://www.ll.mit.edu/llrca2.pem
>  
> There are two ways to design a system. One is to make it so simple
> there are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>  
>  
>   -  C. A. R. Hoare
>  

Re: DH parameter reading in OPENSSL 3

[Mark H. Wood]

On Wed, Jul 13, 2022 at 06:45:48PM +0200, Dirk Stöcker wrote:
> The openssl documentation may be logical for someone who knows all the 
> parts and how they work together, but for everybody else it's a large 
> glob of isolated files which you simply can't bring together. You have 
> pages which sometimes describe dozens of functions which seldom have 
> examples and at least for me they don't help.
> 
> My initial TLS implementation took me days (although I do nothing except 
> loading the parameters (key,cert,chain) and setup the stuff). Mostly I 
> only got that done looking at the openssl tools and how they do it. AFTER 
> you know how the code looks like the documentation helps but not to 
> getting to this state. Essentially for me the documentation thus always 
> was only a means to verify that the examples I used actually are correct 
> and not written by somebody who also doesn't understand it.

This sounds like trying to build something given a Reference Manual
but no Programmer's Guide.

The Reference Manual describes each function, data structure, and file
format in full detail.  It's essential for understanding individual
operations but says nothing about orchestrating them to perform
higher-level tasks.  It's just a complete list of fully-described
features.  As you said, this is where you go to understand code that
already exists or that you have already designed and are writing now.

The Programmer's Guide discusses the logical organization of the
package, how typical higher-level tasks might use individual features
of the package in sequence, which features go together, which are
similar but distinct, and generally what are good ways to think about
working with the product.  IOW it describes many common things that
you can accomplish using those features.  This is where you go for
basic understanding of how to organize a new design in terms of the
available features of the package.

A developer who is not already working with the product on a daily
basis will probably start in the Programmer's Guide when creating a
new design, and have both open when coding.  That's my experience,
anyway.  One more familiar with the package will have less need for
the Guide, but it never becomes entirely unnecessary.

These two ways of thinking about a product are complementary, and a
developer shifts between these modes of thought often while working.

I agree that a Migration Guide will, after a brief discussion of the
high-level differences between old and new, consist mostly of "if you
did task T that way before, now you should do it something like this"
for many values of T drawn from the Programmer's Guide.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [EXTERNAL] Keytool issue with version 3.0.2.

[Mark Hack]

I may have a mixed Java environment. I will recheck on a clean VM when
I get a few minutes.
Regards
Mark Hack
On Thu, 2022-05-19 at 16:46 +0200, Djordje Gavrilovic wrote:
> Hm, not working here. 
> 
>   openjdk version "1.8.0_312" 
> 
>   OpenJDK Runtime Environment (build
>   1.8.0_312-8u312-b07-0ubuntu1-b07) 
> 
>   OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) 
> 
>   
> 
>   Am I correct, the only thing you changed was leaving out the
>   -srcstoretype PKCS12 part? Also, you did not use -legacy option
> on
>   a previous command?
> 
> 
> On 19.5.22. 16:18, Mark Hack wrote:
> 
> 
> 
> >   
> >   
> > 
> >   
> >   I installed java 8 and it seems to work there on the latest
> > versions as well
> >   
> > 
> >   
> >java -version
> >   openjdk version "1.8.0_312"
> >   OpenJDK Runtime Environment (build
> > 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)
> >   OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)
> >   
> > 
> >   
> >   
> > 
> >   
> >   On Thu, 2022-05-19 at 16:02 +0200, Djordje Gavrilovic wrote:
> >   
> > > Thank you both for your answers! So much! Both of them
> > > very
> > >   helpful. We are stuck with openjdk8 right now...but it
> > > is good
> > >   to know that later versions will work as expected.
> > > 
> > >   Thank you guys
> > > 
> > > 
> > > On 19.5.22. 15:41, Mark Hack wrote:
> > > 
> > > 
> > > 
> > > >   
> > > >   Works for me and since the later versions of java
> > > > accept
> > > > both JKS and PKCS12 you do not have to specify the
> > > > input
> > > > store type.
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >java --version
> > > >   openjdk 11.0.15 2022-04-19
> > > >   OpenJDK Runtime Environment (build
> > > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1)
> > > >   OpenJDK 64-Bit Server VM (build
> > > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode,
> > > > sharing)
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   keytool -importkeystore -srckeystore
> > > >   bmstore.pkcs12.pem   -srcstorepass changeit
> > > > -destkeystore
> > > >   bmstore.pkcs8.x509.jks  -deststorepass changeit
> > > >   Importing keystore bmstore.pkcs12.pem to
> > > > bmstore.pkcs8.x509.jks...
> > > >   Entry for alias 1 successfully imported.
> > > >   Import command completed:  1 entries successfully
> > > > imported, 0 entries failed or cancelled
> > > >   
> > > > 
> > > >   
> > > >   Warning:
> > > >   <1> uses the SHA1withRSA signature algorithm which
> > > > is considered a security risk. This algorithm will
> > > > be
> > > > disabled in a future update.
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   Mark Hack
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via
> > > > openssl-users wrote:
> > > >   
> > > > > 
> > > > >   Bonjour,
> > > > >   
> > > > > 
> > > > >   
> > > > >   OpenSSL 3 changed the default ciphers used to
> > > > > protect the
> > > > >   private keys and certificates when creating a
> > > > > PKCS#12, to
> > > > >   use something less aging.
> > > > >   

Re: [EXTERNAL] Keytool issue with version 3.0.2.

[Mark Hack]

I installed java 8 and it seems to work there on the latest versions as
well
 java -versionopenjdk version "1.8.0_312"OpenJDK Runtime Environment
(build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)OpenJDK 64-Bit Server VM
(build 25.312-b07, mixed mode)

On Thu, 2022-05-19 at 16:02 +0200, Djordje Gavrilovic wrote:
> Thank you both for your answers! So much! Both of them very
>   helpful. We are stuck with openjdk8 right now...but it is good
> to
>   know that later versions will work as expected.
> 
>   Thank you guys
> 
> 
> On 19.5.22. 15:41, Mark Hack wrote:
> 
> 
> 
> >   
> >   Works for me and since the later versions of java accept both
> > JKS and PKCS12 you do not have to specify the input store
> > type.
> >   
> > 
> >   
> >   
> > 
> >   
> >java --version
> >   openjdk 11.0.15 2022-04-19
> >   OpenJDK Runtime Environment (build
> > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1)
> >   OpenJDK 64-Bit Server VM (build
> > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)
> >   
> > 
> >   
> >   
> > 
> >   
> >   keytool -importkeystore -srckeystore
> >   bmstore.pkcs12.pem   -srcstorepass changeit -destkeystore
> >   bmstore.pkcs8.x509.jks  -deststorepass changeit
> >   Importing keystore bmstore.pkcs12.pem to
> > bmstore.pkcs8.x509.jks...
> >   Entry for alias 1 successfully imported.
> >   Import command completed:  1 entries successfully imported, 0
> > entries failed or cancelled
> >   
> > 
> >   
> >   Warning:
> >   <1> uses the SHA1withRSA signature algorithm which is
> > considered a security risk. This algorithm will be disabled
> > in a
> > future update.
> >   
> > 
> >   
> >   
> > 
> >   
> >   Mark Hack
> >   
> > 
> >   
> >   
> > 
> >   
> >   On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via
> > openssl-users wrote:
> >   
> > > 
> > >   Bonjour,
> > >   
> > > 
> > >   
> > >   OpenSSL 3 changed the default ciphers used to protect
> > > the
> > >   private keys and certificates when creating a PKCS#12,
> > > to use
> > >   something less aging.
> > >   
> > > 
> > >   
> > >   Try adding a "-legacy" when creating the PKCS#12 file
> > > with OpenSSL3 and see if keytool can read it.
> > >   
> > > 
> > >   
> > > 
> > > 
> > > 
> > > 
> > >   On Thu, May 19, 2022 at
> > > 11:53 AM Djordje Gavrilovic 
> > > wrote:
> > > 
> > >   
> > >   
> > > > Hi guys,
> > > > 
> > > > I have a following issue with migrating from
> > > > version 1.1.1f
> > > > to 3.0.2:
> > > > 
> > > > 
> > > > 
> > > > I generate bmstore.pkcs12.pem file with the
> > > > following
> > > > commands:
> > > > 
> > > > 
> > > > 
> > > > ```
> > > > 
> > > > 
> > > > 
> > > > openssl req -newkey rsa:2048 -sha1 -keyout
> > > > bmstore.pkcs8.pem
> > > > -nodes 
> > > > 
> > > > -x509 -days 999 -out bmstore.x509.crt -subj 
> > > > 
> > > > "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS"
> > > > 
> > > > openssl pkcs12 -export -in bmstore.x509.crt -inkey
> > > > bmstore.pkcs8.pem 
> > > > 
> > > > -out bmstore.pkcs12.pem -passin pass:changeit
> > > > -passout
> > > > pass:changeit
> > > > 
> > > > ```
> > > > 
> > > > 
> > > > 
> > > > This file is genearted with different openssl
> > > > versions
> > > > differently. Both 
> > > > 
> >

Re: [EXTERNAL] Keytool issue with version 3.0.2.

[Mark Hack]

Works for me and since the later versions of java accept both JKS and
PKCS12 you do not have to specify the input store type.

 java --versionopenjdk 11.0.15 2022-04-19OpenJDK Runtime Environment
(build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1)OpenJDK 64-Bit Server VM
(build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)

keytool -importkeystore -srckeystore bmstore.pkcs12.pem   -srcstorepass 
changeit -destkeystore bmstore.pkcs8.x509.jks  -deststorepass
changeitImporting keystore bmstore.pkcs12.pem to
bmstore.pkcs8.x509.jks...Entry for alias 1 successfully imported.Import
command completed:  1 entries successfully imported, 0 entries failed
or cancelled
Warning:<1> uses the SHA1withRSA signature algorithm which is
considered a security risk. This algorithm will be disabled in a future
update.

Mark Hack

On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via openssl-users
wrote:
> Bonjour,
> 
> OpenSSL 3 changed the default ciphers used to protect the private
> keys and certificates when creating a PKCS#12, to use something less
> aging.
> Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3
> and see if keytool can read it.
> 
> 
> 
> On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic <
> gavrilovic...@gmail.com> wrote:
> > Hi guys,
> > 
> > I have a following issue with migrating from version 1.1.1f to
> > 3.0.2:
> > 
> > 
> > 
> > I generate bmstore.pkcs12.pem file with the following commands:
> > 
> > 
> > 
> > ```
> > 
> > 
> > 
> > openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem
> > -nodes 
> > 
> > -x509 -days 999 -out bmstore.x509.crt -subj 
> > 
> > "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS"
> > 
> > openssl pkcs12 -export -in bmstore.x509.crt -inkey
> > bmstore.pkcs8.pem 
> > 
> > -out bmstore.pkcs12.pem -passin pass:changeit -passout
> > pass:changeit
> > 
> > ```
> > 
> > 
> > 
> > This file is genearted with different openssl versions differently.
> > Both 
> > 
> > versions of the file are attached.
> > 
> > 
> > 
> > Based on that file I generate:
> > 
> > 
> > 
> > ```
> > 
> > keytool -importkeystore -srckeystore bmstore.pkcs12.pem
> > -srcstoretype 
> > 
> > PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks 
> > 
> > -deststorepass changeit
> > 
> > ```
> > 
> > 
> > 
> > But keytool works only with the bmstore.pkcs12.pem generated with
> > old 
> > 
> > version of openssl and creates bmstore.pkcs8.x509.jks
> > 
> > 
> > 
> > The current version of openssl generates bmstore.pkcs12.pem in
> > another 
> > 
> > format and keytool throws an exception:
> > 
> > 
> > 
> > ```
> > 
> > Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks...
> > 
> > keytool error: java.io.IOException: keystore password was incorrect
> > 
> > 
> > 
> > ```
> > 
> 
> 

Re: "openssl(1.0.2k) s_client -connect data.reversinglabs.com:443 -tls1_2" gives error: SSL3_GET_RECORD"wrong version number:s3_pkt.c:365

[Mark Hack]

Since you did not give us a lot of information, I compiled the old
openssl version and checked against your server.
OpenSSL 1.0.2 does not send the Server Name Indication and it seems
that your server does not have a default server set up.
Forcing the SNI to be included allows it to connect:
openssl s_client -connect  data.reversinglabs.com:443 -tls1_2
-servername data.reversinglabs.com 


Check your server setup and ensure that a default virtual host has been
defined.
Mark Hack

 On Tue, 2022-05-17 at 15:55 -0400, Geek Geek wrote:
> I run into the following issue when I use openssl 1.0.2k  (amazon
> linux2) to check the connection.
> 
> [ec2-user@ip-172-31-29-28 ~]$ openssl s_client -connect
> data.reversinglabs.com:443 -tls1_2
> CONNECTED(0003)
> 139994515941280:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
> version number:s3_pkt.c:365:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 5 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1652817101
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> 
> 
> [ec2-user@ip-172-31-29-28 ~]$ openssl version
> OpenSSL 1.0.2k-fips  26 Jan 2017
> 
> 
> If I use brew install the latest openssl  (3.0.*), then the same
> command works.   As our production is still using openssl 1.0.2k, my
> question is what causes this error and whether this is really an
> issue.
> 
> Thanks.

Re: CA upgrade in several aspects

[Mark Hack]

NIST-800-131a deprecated SHA1 signatures in January of 2013 along with
RSA1024 bit keys. You should be issuing certificates with at least
RSA2048 with SHA2 signatures, and preferably at least RSA3072 with SHA-
384 signatures and if you are re-issuing CA certs more bits is better.
Nothing was said about CA certificates with SHA1 signatures and some
implementations will now reject these as non-compliant even if they
were issued before 2013.

On Thu, 2022-05-12 at 17:40 +0200, egoitz--- via openssl-users wrote:
> Please ignore the line below I said regards in my previous mail...
> it's there by error...
> 
> 
> cheers!
>  
> 
> 
> El 2022-05-12 17:38, ego...@ramattack.net escribió:
> > Good afternoon,
> > 
> > 
> > I'm running a CA, for generating the certificates for the backup
> > clients of my network and for the backup servers too. The
> > certificates are used for encrypting the backups stored in the
> > servers and too, for comunicating over TLS between severs and
> > clients.
> > 
> > 
> > This CA has some years now and the certificates I generate for new
> > clients, are not working (directly) in new machines. The reason for
> > that is that new operating systems, are requiring stronger signing
> > algorithms. When you try to start the service using that
> > certificates (bacula file daemon) in a fresh new Debian for
> > instance, systemd throws the following error :
> > 
> > 
> > openssl.c:68 Error loading certificate file: ERR=error:140AB18E:SSL
> > routines:SSL_CTX_use_certificate:ca md too weak
> > 
> > 
> > I know you can fix that with the following change in openssl.conf :
> > 
> > 
> > CipherString = DEFAULT@SECLEVEL=2
> > CipherString = DEFAULT@SECLEVEL=1
> > 
> > 
> > But this last way, does not convince me... so I have started
> > debugging what exactly was causing the the problem. I saw, that
> > sha1 is not allowed as a signing valid algorithm for SECLEVEL 2.
> > So, I tried moving the CA to a more recent testing machine (with a
> > newer OpenSSL 1.1.1l-freebsd), and I modified too in the
> > openssl.conf of the CA (The openssl.conf existing in the CA dir for
> > generating certs and so...) :
> > I have attached the old version. The new using version in the
> > testing machine, is the old one plus the below changes :
> > - Added the line : "signer_digest  = sha256"
> > - Modified the line : "digests= md5, sha1" by "digests   
> >  = sha1, sha256, sha384, sha512"
> > - Added the line : "ess_cert_id_alg= sha1"
> > 
> > 
> > Now... I have generated a new certificate by following the normal
> > procedure... generate the key and csr... later sing new cert... etc
> > etc.
> > 
> > 
> > This new generated certificate (signed with sha256WithRSAEncryption
> > algorithm), has worked with a newer version of the Bacula client
> > and in a almost new Debian system. So it seems, just by generating
> > new certificates, using them in that new machines, with a newer os
> > and keeping the old ca certificate, at least the service has
> > started. We have too, another master public key for encrypting
> > content (which is an oldly generated certificate signed with
> > sha1WithRSAEncryption) that we keep in case a customer looses it's
> > keys for avoiding a possible disaster.
> > 
> > 
> > I was wondering if some sort of problem could exist, by using those
> > old two certificates (the master public key and the old ca
> > certifcate) with the new generated certificate.
> > 
> > 
> > Now, that I have that CA, for whose purpose seems to be working, I
> > have started thinking... some more... I have noticed that the CA
> > certificate will expire in 2024. I assume that what I would have to
> > do before that CA cert expires could be :
> > 
> > 
> > - Generate a second ca cert for the CA.
> > - Change the ca certificate to be used (for signing and issuing new
> > certs) in openssl.conf :
> > certificate= $dir/cacert-new.pem # The CA certificate
> > - Sign again all the certificates in the CA...
> > - Change, all certificates in the CA (except the own ca cert which
> > is already changed).
> > - Finally replace in each servers and clients certs.
> > 
> > 
> > Is this a correct procedure for upgrading a CA?. I assume it can be
> > correct. Isn't it?. I think this procedure shouldn't break nothing
> > related to serials of certificates and so in the own ca. Am I
> > wrong?.
> > 
> > 
> > Best regards,
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > +are causing to set a special config in /etc/ssl/openssl.conf
> > saying : "

Re: Fwd: Trying to generate a RSA private key

[Mark Hack]

Use keytool -list -v to ensure that the original store actually
contains a private key
If there is no entry of Entry type: PrivateKeyEntry then the store has
no private key

Mark Hack

On Tue, 2022-02-15 at 18:30 +0100, mary mary wrote:Hello community,
> A beginner here. 
> 
> I would need to extract a private key, PEM or RSA format, from a
> keystore file ("server.keystore") which I have. 
> I've executed:
> 
> keytool -importkeystore -srcstorepass 123456 -srckeystore
> server.keystore -deststorepass 123456 -destkeystore server.p12
> -deststoretype PKCS12
> 
> openssl pkcs12 -in server.p12 -passin pass:123456 -out server-key-
> temp.pem -nodes -nocerts
> 
> But i get an empty file: server-key-temp.pem is empty.
> 
> What's wrong?
> 
> Thank You.
> 
> Kind regards
> 
> 
> 
> 

Re: 回复: openssl-users Digest, Vol 86, Issue 1

[Mark Hack]

You are welcome. Determining why TLS handshakes fail is a challenge
since it does require knowledge of what cipher suites and algorithms
are required by the server and are missing in the client.

On Tue, 2022-01-04 at 23:08 +, Ma Zhenhua wrote:
> Hi Mark,
> 
> 
> 
> 
> 
> 
> 
> Thanks so much for your advice.
>  You're right. This is truely caused by signature_algorithms_cert
> extension not containing rsa_pkcs1_sha256 (0x0401). Below solutions
> now works well regarding TLS handshake.
> 
> 
> 
> 
> 
> 1.The ClientHello doesn't include signature_algorithms_cert
> extension.
> 
> 2.The signature_algorithms_cert extension in ClientHello contains
> rsa_pkcs1_sha256 (0x0401).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> 
> Allen
> 
> 
> 发件人: openssl-users  代表 
> openssl-users-requ...@openssl.org 
> 
> 发送时间: 2022年1月1日 15:48
> 
> 收件人: openssl-users@openssl.org 
> 
> 主题: openssl-users Digest, Vol 86, Issue 1
>  
> 
> 
> 
> Send openssl-users mailing list submissions to
> 
> openssl-users@openssl.org
> 
> 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 
> https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> or, via email, send a message with subject or body 'help' to
> 
> openssl-users-requ...@openssl.org
> 
> 
> 
> You can reach the person managing the list at
> 
> openssl-users-ow...@openssl.org
> 
> 
> 
> When replying, please edit your Subject line so it is more specific
> 
> than "Re: Contents of openssl-users digest..."
> 
> 
> 
> 
> 
> Today's Topics:
> 
> 
> 
>1. RE: undefined symbol: OSSL_provider_init when running "make
> 
>   test" for OpenSSL 3.0 (Lee Staniforth)
> 
>2. RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert
> 
>   (Michael Wojcik)
> 
>3. Re: [openssl-1.1.1l] TLS1.2 Server responses with Alert
> 
>   (Mark Hack)
> 
> 
> 
> 
> 
> ---
> ---
> 
> 
> 
> Message: 1
> 
> Date: Fri, 31 Dec 2021 13:46:49 +
> 
> From: Lee Staniforth 
> 
> To: Matt Caswell , "openssl-users@openssl.org"
> 
> 
> 
> Subject: RE: undefined symbol: OSSL_provider_init when running "make
> 
> test" for OpenSSL 3.0
> 
> Message-ID:
> 
> <
> dm6pr07mb8028dd6128102487938131e882...@dm6pr07mb8028.namprd07.prod.outlook.com
> >
> 
> 
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> Thanks very much, Matt and defulger.
> 
> Removing the "-fvisibility=hidden" has enabled the tests to pass.
> 
> 
> 
> I'll now have to see how my application (which is statically linked
> to OpenSSL) fairs.
> 
> 
> 
> Lee
> 
> 
> 
> From: Matt Caswell 
> 
> Sent: 23 December 2021 10:13
> 
> To: Lee Staniforth ; 
> openssl-users@openssl.org
> 
> Subject: Re: undefined symbol: OSSL_provider_init when running "make
> test" for OpenSSL 3.0
> 
> 
> 
> On 21/12/2021 15:09, Lee Staniforth wrote: > ./Configure linux-x86_64 
> no-shared -m64 -fPIC -fvisibility=hidden Try dropping "-
> fvisibility=hidden". I can replicate this problem when using no-
> shared and
> 
> External (m...@openssl.org<mailto:m...@openssl.org>)
> 
>   Report This Email<
> https://protection.inkyphishfence.com/report?id=c3luY2hyb25vc3MvbGVlLnN0YW5pZm9ydGhAc3luY2hyb25vc3MuY29tL2NiZGFiM2RjZDIzNWI3NDllOWQzYzRlYzBlYTA3Y2I1LzE2NDAyNTQzODIuMzc=#key=1fa1e349d7396284bf7cc883faec871a
> > 
>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<
> https://www.inky.com>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 21/12/2021 15:09, Lee Staniforth wrote:
> 
> 
> 
> > ./Configure linux-x86_64 no-shared -m64 -fPIC -fvisibility=hidden
> 
> 
> 
> 
> 
> 
> 
> Try dropping "-fvisibility=hidden". I can replicate this problem when
> 
> 
> 
> using no-shared and -fvisibility=hidden. If I drop the
> 
> 
> 
> "-fvisibility=hidden" the problem goes away.
> 
> 
> 
> 
> 
> 
> 
> Matt
> 
> -- next part --
> 
> An HTML attachment was scrubbed...
> 
> URL: <
> https://mta.openssl.org/pipermail/openssl-users/attachments/20211231/0f037481/attachment-0001.htm
> >
> 
> 
> 
> --
> 
> 
> 
> Message: 2
> 
> Date: Fri, 31 De

Re: [openssl-1.1.1l] TLS1.2 Server responses with Alert

[Mark Hack]

The server error is correct - the signature_algorithms_cert extension
does not offer rsa_pkcs1_sha256 (0x0401) which is the server
certificate signing algorithm.
If the client is written in Java, check java.security  for
"jdk.certpath.disabledAlgorithms"  and check the constraints.


On Fri, 2021-12-31 at 15:05 +, Michael Wojcik wrote:
> > From: openssl-users  On Behalf
> > Of Ma Zhenhua
> > Sent: Thursday, 30 December, 2021 23:59
> > On the SSL/TLS server, there's one error as follows. 
> > "SSL Error(118) - no suitable signature algorithm"
> 
> Debugging handshake failures isn't my area of expertise, but I note
> both ClientHellos include a signature_algorithms extension, and the
> contents are quite different. In particular, the successful
> ClientHello includes the Signature Hash Algorithm Hash and Signature
> Hash Algorithm Signature parameters, while the failing one doesn't.
> 
> The failing one also includes a signature_algorithms_cert extension,
> while the successful one does not. I don't know offhand how the
> algorithms specified in that extension correspond to the signature-
> algorithm OIDs in signatures, but the server's certificate has
> 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) which seems like it
> ought to correspond to either rsa_pss_rsae_sha256 or
> rsa_pss_pss_sha256. (Apparently those are both RSA-PSS with SHA256,
> as the name implies, and the difference between the two of them is
> whether the public key is encoded using the rsaEncryption format in
> the certificate, or the id-RSASSA-PSS format. The failing client is
> saying it understands both, AIUI.)
> 
> So my guess would be the server is unhappy that the failing client's
> ClientHello doesn't include the parameters for the various supported
> signature schemes in its signature_algorithms extension. But that's
> just a guess, and I don't know how you'd fix it.
> 

Re: Enumerating TLS protocol versions and ciphers supported by the peer

[Mark Hack]

Look at https://testssl.sh/
That is an openssl wrapper which enumerates ciphers and protocols ( and
a whole lot more)
Hexcode  Cipher Suite Name
(OpenSSL)   KeyExch.   Encryption  Bits Cipher Suite Name
(IANA/RFC)-

SSLv2  SSLv3  TLS 1  TLS 1.1  TLS 1.2   xc030   ECDHE-RSA-AES256-GCM-
SHA384   ECDH
521   AESGCM  256  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   
xc02f   ECDHE-RSA-AES128-GCM-SHA256   ECDH
521   AESGCM  128  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   
   TLS 1.3   x1302   TLS_AES_256_GCM_SHA384ECDH
521   AESGCM  256  TLS_AES_256_GCM_SHA384  
x1303   TLS_CHACHA20_POLY1305_SHA256  ECDH
521   ChaCha20256  TLS_CHACHA20_POLY1305_SHA256
x1301   TLS_AES_128_GCM_SHA256ECDH
521   AESGCM  128  TLS_AES_128_GCM_SHA256 

On Mon, 2021-12-06 at 15:06 +, Michael Wojcik wrote:
> > From: Dr. Matthias St. Pierre 
> > Sent: Monday, 6 December, 2021 07:53
> > To: Michael Wojcik ; openssl-
> > 
> > 
> > > "Comparable elegant" is underspecified.
> > 
> > (I guess, "Comparably elegant" would have been grammatically more
> > correct.)
> 
> I just meant that elegance is in the eye of the beholder.
> 
> Many people might agree that having a single command line return the
> list of what suites the server supports is elegant, at least for the
> user. Others prefer the original UNIX philosophy of simpler tools
> which are scripted to perform more complex operations; that's the
> testssl.sh approach, and it's more elegant in the sense of being
> composed in a visible (and modifiable) way from smaller pieces.
> 
> A command-line option to s_client to do this sort of server profiling
> is conceivable, but it would be a significant departure from what
> s_client does now, since it would conflict with some other options
> and would involve making multiple connections. That doesn't mean it
> shouldn't be implemented, necessarily, just that it's not parallel to
> most of the other things s_client options do.
> 
> -- 
> Michael Wojcik

OpenSSL is looking to hire two full-time positions: Developer, and Manager

[Mark J Cox]

OpenSSL is looking to hire two full-time positions: Developer, and
Manager. Details of the roles can be found here:

https://www.openssl.org/blog/blog/2021/11/24/hiring-manager-and-developer/

To apply please send your cover letter and resume to j...@openssl.org
by 9th December 2021

Regards,
The OpenSSL Project Team

Re: how to enable DHE ciphers on openssl for using on command line

[Mark Hack]

"openssl ciphers" will show you the correct names which in this case is
DHE-RSA-AES128-GCM-SHA256

On Wed, 2021-11-17 at 16:25 +0800, M K Saravanan wrote:
> Hi,
> 
> Do I need to do any config to enable DHE based ciphers in openssl for
> command line usage?
> 
> $ openssl s_client -cipher 'DHE_RSA_WITH_AES_128_GCM_SHA256' -connect
> 10.10.16.100:443
> Error with command: "-cipher DHE_RSA_WITH_AES_128_GCM_SHA256"
> 139775998456896:error:140E6118:SSL
> routines:ssl_cipher_process_rulestr:invalid
> command:ssl/ssl_ciph.c:1028:
> 
> mksarav@ubuntu1804:~$ openssl version
> OpenSSL 1.1.1d  10 Sep 2019
> 
> Non DHE ciphers are working fine with the above command option.  Are
> they purposely removed for security reasons? I need to use DHE
> ciphers
> for some testing purpose. Is there anyway can I use it?
> 
> 
> with regards,
> Saravanan

Re: OpenSSL 3.0.0 enabling SSLv3 support

[Mark Hack]

Added to all the weaknesses in SSLv3, the only supported cipher suites
are either vulnerable  or deprecated and not advisable.

 SSL_RSA_WITH_NULL_MD5   NULL-MD5
 SSL_RSA_WITH_NULL_SHA   NULL-SHA
 SSL_RSA_EXPORT_WITH_RC4_40_MD5  EXP-RC4-MD5
 SSL_RSA_WITH_RC4_128_MD5RC4-MD5
 SSL_RSA_WITH_RC4_128_SHARC4-SHA
 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5  EXP-RC2-CBC-MD5
 SSL_RSA_WITH_IDEA_CBC_SHA   IDEA-CBC-SHA
 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-DES-CBC-SHA
 SSL_RSA_WITH_DES_CBC_SHADES-CBC-SHA
 SSL_RSA_WITH_3DES_EDE_CBC_SHA   DES-CBC3-SHA

 SSL_DH_DSS_WITH_DES_CBC_SHA DH-DSS-DES-CBC-SHA
 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHADH-DSS-DES-CBC3-SHA
 SSL_DH_RSA_WITH_DES_CBC_SHA DH-RSA-DES-CBC-SHA
 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHADH-RSA-DES-CBC3-SHA
 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
 SSL_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA
 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA
 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
 SSL_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA

 SSL_DH_anon_EXPORT_WITH_RC4_40_MD5  EXP-ADH-RC4-MD5
 SSL_DH_anon_WITH_RC4_128_MD5ADH-RC4-MD5
 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA   EXP-ADH-DES-CBC-SHA
 SSL_DH_anon_WITH_DES_CBC_SHAADH-DES-CBC-SHA
 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA   ADH-DES-CBC3-SHA

 SSL_FORTEZZA_KEA_WITH_NULL_SHA  Not implemented.
 SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  Not implemented.
 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA   Not implemented.

On Wed, 2021-10-06 at 11:25 -0700, Kory Hamzeh wrote:
> Fair enough. We are not using SSLv3, the code just made reference to
> the method. I will compile it out.
> 
> Thanks!
> 
> 
> > On Oct 5, 2021, at 5:09 PM, Viktor Dukhovni <
> > openssl-us...@dukhovni.org> wrote:
> > 
> > On Tue, Oct 05, 2021 at 03:49:48PM -0700, Kory Hamzeh wrote:
> > 
> > > It looks like SSLv3 is not built by default in OpenSSL 3.0.0. At
> > > least
> > > SSLv3_method() is not define, and looking at the conditional
> > > compilation of that function, it makes sense.
> > > 
> > > What command line option do I pass the Configure script to enable
> > > it?
> > > I tried enable-sslv3 and  enable-SSLv3. It complained about both.
> > > I
> > > need to compile some old code (Python 2.7) which we will abandon
> > > soon.
> > 
> > Don't enable SSLv3 in OpenSSL 3.0, that's not doing anyone a
> > favour.
> > Better to instead build the code in question against OpenSSL 1.1.1,
> > if
> > SSLv3 actually needs to be *used*.  It is not a problem to install
> > both
> > OpenSSL 1.1.1 and OpenSSL 3.0 side-by-side (shared libraries) on
> > systems
> > with support for symbol versioning.
> > 
> > If the only purpose of SSLv3 is to get code to compile, that will
> > not
> > in fact ever run, or that can reasonably just return an error when
> > it runs, you can enable the method stubs, without enabling support
> > for the protocol:
> > 
> >./Configure enable-ssl3-method ...
> > 
> > The default is to disable both "ssl3" and "ssl3-protocol" and I
> > would
> > strongly encourage you to not enable both.  Nobody should be
> > actually
> > using SSLv3 anymore, but exporting function stubs that will error
> > out
> > makes some sense if required to support toolkits that wrap the
> > OpenSSL
> > API and still want to expose SSLv3 methods.
> > 
> > -- 
> >Viktor.
> 
> 

Re: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher.

[Mark Hack]

The docs are not the easiest to follow so here is what I did to order
curves from strongest to weakest.The file is /etc/pki/tls/openssl.conf
and should be close to your settings. Set the curves to what you want
as I did in the Curve line

openssl_conf = default_modules

[ default_modules ]

ssl_conf = ssl_module

[ ssl_module ]

system_default = crypto_policy

[ crypto_policy ]
Curves = P-521:P-384:P-256



On Fri, 2021-07-02 at 15:53 +0100, Matt Caswell wrote:
> 
> On 02/07/2021 14:02, vinod mg wrote:
> > --> Is there a way I can compile openssl itself to exclude
> > 'secp521r1' 
> > and install? The reason I ask is because application I am testing
> > is 
> > squid(squid-cache.org ) for ssl bumping
> > purposes 
> > and it has limited configurability.
> 
> Only by disabling *all* ec groups (via the "no-ec" configure option)
> but 
> that is no solution at all really. I would not recommend that!
> 
> You might try starting squid with the OPENSSL_CONF environment
> variable 
> pointing to a custom OpenSSL config file. Assuming squid doesn't 
> suppress loading the config file then you can do the same thing as 
> SSL_CTX_set1_groups_list via the "Groups" SSL_CONF setting. See the
> info 
> here on configuring OpenSSL SSL/TLS settings via config file (see
> the 
> section "SSL Configuration Module"):
> 
> https://www.openssl.org/docs/man1.1.1/man5/config.html
> 
> And see the documentation on "Groups" on this page:
> 
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
> 
> Matt
> 
> > 
> > Thanks,
> > Vinod
> > 
> > 
> > On Fri, Jul 2, 2021 at 4:32 PM Matt Caswell  > > wrote:
> > 
> > 
> > 
> > On 01/07/2021 07:21, vinod mg wrote:
> >  > 1) Supress or a way to remove secp521r1 from the
> > currenlty
> > installed
> >  > openssl.
> > 
> > You can specify the list of groups by calling
> > SSL_CTX_set1_groups_list
> > (or SSL_set1_groups_list) from your application. See:
> > 
> > 
> > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html
> > <
> > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html
> > >
> > 
> >  > 2) Add the cipher - "0xbaba   TLS_GREASE_BA   GREASE"
> > like we
> > see in
> >  > chrome.
> > 
> > This is not a real cipher. It does nothing and is always
> > ignored.
> > OpenSSL does not support sending this value.
> > 
> > Matt
> > 
> > 
> >  >
> >  > I am ok with custom install as well, if above cannot be
> > done with
> >  > already installed openssl package. Please share any wiki
> > I can
> >  > follow to impliment the same.
> >  >
> >  > ~]# openssl ecparam -list_curves
> >  >
> >  > secp224r1 : NIST/SECG curve over a 224 bit prime field
> >  >
> >  > secp256k1 : SECG curve over a 256 bit prime field
> >  >
> >  > secp384r1 : NIST/SECG curve over a 384 bit prime field
> >  >
> >  > /secp521r1 : NIST/SECG curve over a 521 bit prime field/
> >  >
> >  > prime256v1: X9.62/SECG curve over a 256 bit prime field
> >  >
> >  >
> >  > I am using below OS and version-
> >  >
> >  > # cat /etc/redhat-release
> >  >
> >  > Red Hat Enterprise Linux release 8.3 (Ootpa)
> >  >
> >  >
> >  > # opensslversion -a
> >  >
> >  > OpenSSL 1.1.1g FIPS21 Apr 2020
> >  >
> >  > built on: Thu Mar 25 16:46:53 2021 UTC
> >  >
> >  > platform: linux-x86_64
> >  >
> >  > options:bn(64,64) md2(char) rc4(16x,int) des(int)
> > idea(int)
> >  > blowfish(ptr)
> >  >
> >  > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack
> > -Wall -O3
> > -O2 -g
> >  > -pipe -Wall -Werror=format-security -Wp,-
> > D_FORTIFY_SOURCE=2
> >  > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-
> > protector-strong
> >  > -grecord-gcc-switches
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> >  > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
> > -mtune=generic
> >  > -fasynchronous-unwind-tables -fstack-clash-protection
> >  > -fcf-protection -Wa,--noexecstack
> >  > -Wa,--generate-missing-build-notes=yes
> >  > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > -DOPENSSL_USE_NODELETE
> >  > -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
> > -DOPENSSL_IA32_SSE2
> >  > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> > -DOPENSSL_BN_ASM_GF2m
> >  > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM
> > -DRC4_ASM
> >  > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM
> > -DECP_NISTZ256_ASM
> >  > -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY
> >  > -DDEVRANDOM="\"/dev/urandom\""
> >  >   
> >   -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-
> > ends/openssl.config"
> >  >
> >  > OPENSSLDIR: "/et

Re: How to query current settings/policies?

[Mark H. Wood]

On Tue, Jun 22, 2021 at 02:53:07PM +0200, Tomas Mraz wrote:
> On Tue, 2021-06-22 at 14:12 +0200, Thomas Deutschmann wrote:
> > Hi,
> > 
> > with OpenSSL 3 defaulting to TLS security level 1, applications
> > trying 
> > to make a TLSv1/1.1 connection will fail.
> > 
> > I wonder if there is a proper way to detect current security level.
> > 
> > I.e. how about test suites which need to know if they have to skip a 
> > test or not?
> > 
> > For example, I am currently looking at MySQL which has a test to
> > ensure, 
> > that you are still able to connect to TLS 1.3 enabled server with 
> > TLSv1/1.1: 
> > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test
> > 
> > The test already knows about the fact that system could have
> > restricted 
> > minimum TLS version, see 
> > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc
> > 
> > However, this solution isn't stable: It's just parsing some files
> > from 
> > hard coded paths (what about OPENSSL_CONF environment variable?) and 
> > guesses.
> > 
> > Furthermore it knows nothing about Gentoo Linux for example. But
> > even 
> > with Ubuntu, you could have a policy in place which overrides set 
> > OPENSSL_TLS_SECURITY_LEVEL=2 from configure.
> > 
> > Is there a way to use openssl CLI to query this information and
> > allow 
> > test suites for example to skip tests on a more reliable way? Or
> > what's 
> > the recommended way for tests?
> 
> There is already such feature request:
> https://github.com/openssl/openssl/issues/14570
> 
> Unfortunately it was not implemented in time for beta1 so this is now
> Post 3.0 item.
> 
> I would recommend explicitly setting security level 0 via a cipher
> string when executing the test.

I second the motion.  If a test is sensitive to some setting of the
code under test, then the test should set it.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Request Assistance::No X509TrustManager implementation available

[Mark Hack]

This is a Java error and not an openSSL error.  This will be thrown if
the application did not specify a valid X509 Trust Manager for the
SSLContext.



On Fri, 2021-04-30 at 15:48 +0530, K V Rao via openssl-users wrote:
No X509TrustManager implementation available

Re: facing issue in sha512 self - signed certificate

[Mark Hack]

You will need to be a lot more specific - this works fine

openssl s_client -connect localhost:443 | openssl x509 -noout -text
Can't use SSL_get_servername
depth=0 C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5d:72:e6:0c:24:3f:97:7f:66:09:f6:a5:f7:f8:96:95:ed:cb:26:59
Signature Algorithm: sha512WithRSAEncryption
Issuer: C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
Validity
Not Before: Apr 22 14:22:50 2021 GMT
Not After : Apr 22 14:22:50 2022 GMT
Subject: C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:b8:c0:72:0e:81:ec:49:fd:6d:06:c2:15:1c:a7:

cf:5c:cb
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: 
7A:E4:80:D6:86:BF:03:BE:3C:16:C6:99:B7:66:BE:CE:52:F7:96:F2
X509v3 Authority Key Identifier: 
keyid:7A:E4:80:D6:86:BF:03:BE:3C:16:C6:99:B7:66:BE:CE:52:F7:96:F2

X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha512WithRSAEncryption
27:1e:c7:f4:7a:7e:43:39:1f:3d:8b:08:94:67:bf:9d:e9:38:

a5:fb:21:9c:d7:f5:28:67
On Thu, 2021-04-22 at 18:22 +0530, Vadivel P wrote:
> Hi All,
> 
> Looking for the same support of SHA512. Do we have sha512 support in
> any open source ? Please let me know.
> 
> Regards,
> Vadivel
> 
> On Mon, Apr 19, 2021, 13:15 preethi teekaraman <
> preethi.kav...@gmail.com> wrote:
> > Hi Openssl,
> > 
> > I'm creating sha512 self signed certificate for establishing
> > connection between client and server(nginx server). 
> > creating separate key, cert for server and root cert for client. 
> > below is the link i followed for cert creation: 
> > https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309
> > 
> > Issue faced : 
> > There's no connection established and we cross-checked error log in
> > server no error observed. 
> > 
> > Openssl version : OpenSSL 1.0.1f 6 Jan 2014
> > 
> > 
> > nginx version: nginx/1.4.6 (Ubuntu)
> > 
> > 
> > OS version 
> > 
> > 
> > No LSB modules are available.
> > 
> > 
> > Distributor ID:Ubuntu
> > 
> > 
> > Description:   
> > Ubuntu 14.04.5 LTS
> > 
> > 
> > Release:  
> > 14.04
> > 
> > 
> > Codename:trusty
> > 
> > is there any link or commands to follow while creating cert for
> > sha512. ?
> > 
> > Regards,
> > Preethi Teekaraman.

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Mark Hack]

RFC6066

   Note that when a list of URLs for X.509 certificates is used, the
   ordering of URLs is the same as that used in the TLS Certificate
   message (see [RFC5246], Section 7.4.2), but opposite to the order in
   which certificates are encoded in PkiPath.  In either case, the
self-signed root certificate MAY be omitted from the chain, under the
   assumption that the server must already possess it in order to
   validate it.


On Wed, 2021-03-31 at 14:09 -0400, Viktor Dukhovni wrote:
> > On Mar 31, 2021, at 2:04 PM, Walter H. 
> > wrote:
> > 
> > On 31.03.2021 19:48, Viktor Dukhovni wrote:
> > > > On Mar 31, 2021, at 1:43 PM, Michael Wojcik <
> > > > michael.woj...@microfocus.com> wrote:
> > > > 
> > > > As far as I can see, neither PKIX (RFC 5280) nor the CA/BF
> > > > Baseline Requirements say anything about the practice, though I
> > > > may have missed something. I had a vague memory that some
> > > > standard or "best practice" guideline somewhere said the server
> > > > should send the chain up to but not including the root, but I
> > > > don't know what that might have been.
> > > 
> > > Inclusion of the self-signed root is harmless.
> > 
> > do some admins this really?
> 
> Since it is possible to do, inevitably some will do it.
> 
> > > The only case that
> > > I know of where this is actually necessary is with DANE-TA(2)
> > > when
> > > the TLSA RRset has a hash of the trusted root cert or public key.
> > > 
> > 
> > this case is history, there doesn't exist any user agent, which has
> > implemented this;
> 
> Well, that's false, just because you're not familiar with it, does
> not
> mean it does not exist.  OpenSSL, Postfix, Exim, Halon MTA, Cisco
> ESA,
> PowerMTA, ... all support DANE, including DANE-TA(2).
> 
> Yes, no major browsers as yet supports DANE.  But not all TLS is
> HTTPS
> and not all HTTPS is browsers viewing websites.
> 

Offloading EC_POINT_mul via engine

[GODFREY Mark]

I have successfully been able to offload specific ECC functionality via my own 
engine.  For example, I have been able to offload sign, verify and compute_key 
methods. My latest task is now to offload, specifically, ECC point 
multiplication.  I am having a hard go at this. Really looking for guidance as 
to how to accomplish this.  I originally started by trying to create my own 
EC_METHOD that has a function pointer to my own point multiplication function, 
but that does not compile as EC_METHOD is now not accessible (in OpenSSL 
1.1.1).  What I am looking to do is every time EC_POINT_mul is called to call 
my homegrown function.  Is this even possible?  Any guidance or reading 
materials would be helpful.  Thanks in advance.

Re: How to disable renegation before compiling openssl

[Mark Windshield]

Thanks for you reply Ben!

Sorry for being unclear, the goal would be to just not send the SCSV value
in the ClientHello.

-Mark

Am Di., 21. Apr. 2020 um 22:06 Uhr schrieb Benjamin Kaduk :

> On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote:
> > Hello,
> >
> > I was wondering what I'd have to change in the openssl code/config before
> > compiling to have renegation disabled by default, so it won't send the
> > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.
>
> This description does not really make it clear whether you just want to
> prevent
> renegotiation or specifically need this SCSV value to not be included in
> the
> ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if
> renegotiation occurs, the client supports the 'secure' variant", but is
> otherwise orthogonal to whether renegotiation itself actually occurs.
>
> -Ben
>

How to disable renegation before compiling openssl

[Mark Windshield]

Hello,

I was wondering what I'd have to change in the openssl code/config before
compiling to have renegation disabled by default, so it won't send the
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.

Thanks!

Re: Questions about secure curves

[Mark Hack]

I believe that Firefox does still support P-521 but Chrome does not. 
Also be aware that if you set server side cipher selection and use
default curves, that OpenSSL orders the curves weakest to strongest (
even with @STRENGTH) so you will end up forcing P-256.


On Tue, 2019-10-15 at 17:24 +0200, Jakob Bohm via openssl-users wrote:
> On 15/10/2019 15:43, Stephan Seitz wrote:
> > Hi!
> > 
> > I was looking at the output of „openssl ecparam -list_curves” and 
> > trying to choose a curve for the web server together with
> > letsencrypt.
> > 
> > It seems, letsencrypt supports prime256v1, secp256r1, and
> > secp384r1.
> > 
> > Then I found the site https://safecurves.cr.yp.to/.
> > I have problems mapping the openssl curves with the curve names
> > from 
> > the web site, but I have the feeling that none of the choices
> > above 
> > are safe.
> > 
> 
> safecurves.cr.yp.to lists some curves that Daniel J. Bernstein
> (who runs the cr.yp.to domain) wants to promote, and emphasizes
> problems with many other popular curves.
> 
> prime256v1 = secp256r1 = P-256 and secp384r1 = P-384 are two curves
> that the US government (NIST in cooperation with NSA) wants to
> promote.
> 
> It so happens that the CA/Browser forum has mysteriously decided
> that the big (US made) web browsers should only trust CAs that
> only accept curves that the US government promotes.  So if you
> want your SSL/TLS implementation to work with widely distributed
> US Browsers (Chrome, Safari, Firefox, IE, Edge etc.) you have to
> use the US government curves P-256 and P-384 .  The third US
> governmentcurve P-521 is banned by Firefox, so no trusted CA can
> support it.
> 
> 
> Enjoy
> 
> Jakob

Re: TLS does not invoke hardware acceleration except on Intel/AMD platform

[Mark Hack]

This was on 1.0.2 and I just checked 1.1.1, and for libssl I still only
see the call for libcrypto. I can recompile and confirm later in the
day to be 100% certain.



On Wed, 2019-09-25 at 16:26 +0100, Matt Caswell wrote:
> 
> On 25/09/2019 15:26, Mark Hack wrote:
> > ssl_algs.c is missing the required call to OPENSSL_cpuid_setup()
> > which
> > means that all the platforms which rely on the CPU ID to be set
> > (everything except Intel/AMD) never use any of the EVP calls and do
> > not
> > hardware accelerate TLS. Yes, the performance tests work but these
> > do
> > not use libssl.
> > 
> > Patching ssl_algs.c corrects this and the performance improvement
> > is
> > immediatly noticable. This is the patch applied and tested on PPC.
> > 
> > int SSL_library_init(void)
> > {
> > OPENSSL_cpuid_init_setup(); /* Identify the HW platform */
> > 
> > ...
> 
> Which version of OpenSSL do you see this in? In 1.1.1 at least I see
> the call to
> OPENSSL_cpuid_setup() in the default initialisation code:
> 
> 
https://github.com/openssl/openssl/blob/19bd1fa1ef17ff0ac071402cb6b002f1c29e37b9/crypto/init.c#L45-L70
> 
> Matt
> 

TLS does not invoke hardware acceleration except on Intel/AMD platform

[Mark Hack]

ssl_algs.c is missing the required call to OPENSSL_cpuid_setup() which
means that all the platforms which rely on the CPU ID to be set
(everything except Intel/AMD) never use any of the EVP calls and do not
hardware accelerate TLS. Yes, the performance tests work but these do
not use libssl.

Patching ssl_algs.c corrects this and the performance improvement is
immediatly noticable. This is the patch applied and tested on PPC.

int SSL_library_init(void)
{
OPENSSL_cpuid_init_setup(); /* Identify the HW platform */

...

Regards

Mark Hack

Re: How do I build an app with 1.1.1 that uses libraries built against 1.0.2?

[Mark Richter]

nm says there are no symbols in libssl or libcrypto.

It also says that libcurl has no symbols.  Does that imply that all libcurl's 
symbols are already resolved?

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403



From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Monday, July 22, 2019 10:46 AM
To: openssl-users@openssl.org
Subject: Re: How do I build an app with 1.1.1 that uses libraries built against 
1.0.2?

On Mon, Jul 22, 2019 at 04:50:46PM +0000, Mark Richter wrote:

> We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 
> 1.0.2, but our app needs 1.1.1.
>
> I'm not at all sure how to set up our Makefile to handle this.

The libcurl shared library will be looking for "libssl.so.1.0.0"
and "libcrypto.so.1.0.0" with associated symbol versions, assuming
the RHEL 7 OpenSSL libraries in /usr/lib employ symbol versioning.

Under the above assumptions, once you have the "shlib_variant"
OpenSSL built, you can just link:

cc -o application application.o \
-L/opt/openssl1.1 -Wl,-rpath,/opt/openssl1.1/lib -lssl -lcrypto \
-lcurl \
...

With the OpenSSL libraries listed before libcurl, just in case your
linker automatically searches nested dependencies first and ends up
linking application.o against libcurl's choice of OpenSSL libraries.

This works on Debian systems where base system's libssl and libcrypto
have symbol versions.

If, however, the system libssl and libcrypto lack symbol versions,
(do they on RHEL 7?) then libcurl will not be explicitly bound to
the base-system OpenSSL API, and depending on the order in which
libraries are loaded may inadvertently end up with the 1.1.1 symbol
bindings (and then fail).

In that case it may be helpful to list libcurl first, hoping that
it will be loaded first, and resolved against the system OpenSSL,
with the variant OpenSSL for your application loaded second, assuming
that the "dependents of dependents" issue is not a problem.  But
at the end of the day, that is probably too fragile, you might
also load more libraries at runtime, and those could end up with
the wrong symbols.

So if your base system's libssl and libcrypto have no symbol versions,
you just have to accept the fact that you're stuck with the system
OpenSSL libraries for better or worse.

--
Viktor.
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

How do I build an app with 1.1.1 that uses libraries built against 1.0.2?

[Mark Richter]

I thought I'd start a new thread for this as it may have been buried in my 
other thread.


We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 1.0.2, 
but our app needs 1.1.1.


I'm not at all sure how to set up our Makefile to handle this.


Thanks.

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com<http://www.solarflare.com/>
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

Re: Error building app on RHEL 7 with openssl 1.1.1

[Mark Richter]

I forgot to mention that this round was on CentOS 7, and the tests fail with or 
without the variant changes.

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403



From: openssl-users  on behalf of Mark 
Richter 
Sent: Friday, July 19, 2019 3:13 PM
To: openssl-users@openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I figured out the variant issue and built, but the tests are failing - see 
https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129.

Still not sure how to link an app to the new ssl that uses libraries that were 
built with the default.

-Original Message-
From: openssl-users  On Behalf Of Mark 
Richter
Sent: Friday, July 19, 2019 11:04 AM
To: openssl-users@openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I've been poking around in the Configurations/* and all the README* files, and 
on the web, and it is not at all clear to me how/where to specify the 
inherit_from and shlib_variant options (probably not the right term, but...) or 
how the resulting libraries are distinguished from the system defaults from the 
app Makefile and resulting application's point of view, particularly w.r.t. how 
our app can use 1.1.1 while libraries we also link will use the system default 
(1.0.2).

Do I copy an existing .conf file to a new name and edit that?  If so, what am I 
editing from/to?  What's the best way to choose the name for the new file?

How do I get config (or Configure) to use the new conf file, or is that 
automatic?  If it is automatic, how does that work for "my" platform?

Assuming I use both, do I need to change my source to make use of the new 
libraries or just my Makefile (and how)?

Our app links to both crypto/ssl and other shared libraries that use the system 
default.  How do I tell my Makefile which one to use for both our app and the 
other libraries which need to use the system default openssl crypto/ssl libs?  
Do I tack the variant at the front or back end of the -L/-l spec lines?  What 
about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app 
needs since we don't care what the other libraries use for compiling)?

As I mentioned, this is all quite new to me.

My apologies if this is as painful for you as it has been for me.

Many, many thanks in advance.  I deeply appreciate all your assistance.

Mark

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: openssl-users@openssl.org
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter  wrote:
>
> cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ 
> -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 
> -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 
> 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms 
> -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include 
> -I/usr/include/json-c   -g3 -fno-omit-frame-pointer -Isrc/cntlr 
> build/src/cntlr/cntlr.o -o build/bin/cntlr  -Lbuild/lib -L/opt/openssl1.1/lib 
> -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto  -lpci -lcurl 
> -lpthread -lrt -lssl -luuid -ljson-c
> /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined 
> reference to symbol 'dlclose@@GLIBC_2.2.5'
> /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> make: *** [build/bin/cntlr] Error 1

While dlopen issue can be resolved by including "-ldl" in your linker options.

If you have not managed to get "shlib_variant" working, the above can't 
possibly work because the libcurl you're linking with likely expects the 
OpenSSL 1.0.2 ABI.  If the same symbols are found in your the 1.1.1 library in 
/opt, libcurl will likely crash.

If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant 
SONAMEs and symbol variants, it should work. In that case libcurl will find its 
symbols in something like:

/usr/lib/libssl.1.0.so

While your application can directly use the OpenSSL 1.1.1 API.
If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do 
you no good, unless you also built a custom libcurl linked against the custom 
OpenSSL.

Perhaps you're looking for "Nix", or similar where multiple versions of 
dependents and dependencies coëxist more broadly on the same system (though 
still likely not multiple versions of the same library in the same address 
spaces as with the shlib_variant approach), but that's really not RHEL anymore.

--
Viktor.

The information contained in this message is confidential and is intended for 
the addres

RE: Error building app on RHEL 7 with openssl 1.1.1

[Mark Richter]

I figured out the variant issue and built, but the tests are failing - see 
https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129.

Still not sure how to link an app to the new ssl that uses libraries that were 
built with the default.

-Original Message-
From: openssl-users  On Behalf Of Mark 
Richter
Sent: Friday, July 19, 2019 11:04 AM
To: openssl-users@openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I've been poking around in the Configurations/* and all the README* files, and 
on the web, and it is not at all clear to me how/where to specify the 
inherit_from and shlib_variant options (probably not the right term, but...) or 
how the resulting libraries are distinguished from the system defaults from the 
app Makefile and resulting application's point of view, particularly w.r.t. how 
our app can use 1.1.1 while libraries we also link will use the system default 
(1.0.2).

Do I copy an existing .conf file to a new name and edit that?  If so, what am I 
editing from/to?  What's the best way to choose the name for the new file?

How do I get config (or Configure) to use the new conf file, or is that 
automatic?  If it is automatic, how does that work for "my" platform?

Assuming I use both, do I need to change my source to make use of the new 
libraries or just my Makefile (and how)?

Our app links to both crypto/ssl and other shared libraries that use the system 
default.  How do I tell my Makefile which one to use for both our app and the 
other libraries which need to use the system default openssl crypto/ssl libs?  
Do I tack the variant at the front or back end of the -L/-l spec lines?  What 
about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app 
needs since we don't care what the other libraries use for compiling)?

As I mentioned, this is all quite new to me.

My apologies if this is as painful for you as it has been for me.

Many, many thanks in advance.  I deeply appreciate all your assistance.

Mark

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: openssl-users@openssl.org
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter  wrote:
>
> cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ 
> -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 
> -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 
> 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms 
> -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include 
> -I/usr/include/json-c   -g3 -fno-omit-frame-pointer -Isrc/cntlr 
> build/src/cntlr/cntlr.o -o build/bin/cntlr  -Lbuild/lib -L/opt/openssl1.1/lib 
> -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto  -lpci -lcurl 
> -lpthread -lrt -lssl -luuid -ljson-c
> /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined 
> reference to symbol 'dlclose@@GLIBC_2.2.5'
> /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> make: *** [build/bin/cntlr] Error 1

While dlopen issue can be resolved by including "-ldl" in your linker options.

If you have not managed to get "shlib_variant" working, the above can't 
possibly work because the libcurl you're linking with likely expects the 
OpenSSL 1.0.2 ABI.  If the same symbols are found in your the 1.1.1 library in 
/opt, libcurl will likely crash.

If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant 
SONAMEs and symbol variants, it should work. In that case libcurl will find its 
symbols in something like:

/usr/lib/libssl.1.0.so

While your application can directly use the OpenSSL 1.1.1 API.
If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do 
you no good, unless you also built a custom libcurl linked against the custom 
OpenSSL.

Perhaps you're looking for "Nix", or similar where multiple versions of 
dependents and dependencies coëxist more broadly on the same system (though 
still likely not multiple versions of the same library in the same address 
spaces as with the shlib_variant approach), but that's really not RHEL anymore.

--
Viktor.

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.
The information contained in this message is confidential and is intended for 
the addres

RE: Error building app on RHEL 7 with openssl 1.1.1

[Mark Richter]

I've been poking around in the Configurations/* and all the README* files, and 
on the web, and it is not at all clear to me how/where to specify the 
inherit_from and shlib_variant options (probably not the right term, but...) or 
how the resulting libraries are distinguished from the system defaults from the 
app Makefile and resulting application's point of view, particularly w.r.t. how 
our app can use 1.1.1 while libraries we also link will use the system default 
(1.0.2).

Do I copy an existing .conf file to a new name and edit that?  If so, what am I 
editing from/to?  What's the best way to choose the name for the new file?

How do I get config (or Configure) to use the new conf file, or is that 
automatic?  If it is automatic, how does that work for "my" platform?

Assuming I use both, do I need to change my source to make use of the new 
libraries or just my Makefile (and how)?

Our app links to both crypto/ssl and other shared libraries that use the system 
default.  How do I tell my Makefile which one to use for both our app and the 
other libraries which need to use the system default openssl crypto/ssl libs?  
Do I tack the variant at the front or back end of the -L/-l spec lines?  What 
about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app 
needs since we don't care what the other libraries use for compiling)?

As I mentioned, this is all quite new to me.

My apologies if this is as painful for you as it has been for me.

Many, many thanks in advance.  I deeply appreciate all your assistance.

Mark

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: openssl-users@openssl.org
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter  wrote:
>
> cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ 
> -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 
> -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 
> 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms 
> -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include 
> -I/usr/include/json-c   -g3 -fno-omit-frame-pointer -Isrc/cntlr 
> build/src/cntlr/cntlr.o -o build/bin/cntlr  -Lbuild/lib -L/opt/openssl1.1/lib 
> -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto  -lpci -lcurl 
> -lpthread -lrt -lssl -luuid -ljson-c
> /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined 
> reference to symbol 'dlclose@@GLIBC_2.2.5'
> /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> make: *** [build/bin/cntlr] Error 1

While dlopen issue can be resolved by including "-ldl" in your linker options.

If you have not managed to get "shlib_variant" working, the above can't 
possibly work because the libcurl you're linking with likely expects the 
OpenSSL 1.0.2 ABI.  If the same symbols are found in your the 1.1.1 library in 
/opt, libcurl will likely crash.

If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant 
SONAMEs and symbol variants, it should work. In that case libcurl will find its 
symbols in something like:

/usr/lib/libssl.1.0.so

While your application can directly use the OpenSSL 1.1.1 API.
If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do 
you no good, unless you also built a custom libcurl linked against the custom 
OpenSSL.

Perhaps you're looking for "Nix", or similar where multiple versions of 
dependents and dependencies coëxist more broadly on the same system (though 
still likely not multiple versions of the same library in the same address 
spaces as with the shlib_variant approach), but that's really not RHEL anymore.

--
Viktor.

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

Error building app on RHEL 7 with openssl 1.1.1

[Mark Richter]

This is probably along the same lines as other questions I have hasked.

I built the 1.1.1 libraries and installed them in /opt/openssl1.1, then 
modified the Makefile to include the right -I and -L flags, but I get this 
error:

cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ 
-D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 
(3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include 
-I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include 
-Isrc/emulators/mbedtls/include -I/usr/include/json-c   -g3 
-fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr  
-Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm 
-lss -lcrypto  -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c
/usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference 
to symbol 'dlclose@@GLIBC_2.2.5'
/usr/lib64/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [build/bin/cntlr] Error 1

What am I missing?

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com<http://www.solarflare.com/>
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

RE: Errors building 1.1.1 on RHEL 7

[Mark Richter]

> -Original Message-
> From: openssl-users  On Behalf Of Viktor 
> Dukhovni
> Sent: Wednesday, July 17, 2019 12:42 PM
> To: openssl-users@openssl.org
> Subject: Re: Errors building 1.1.1 on RHEL 7
>:
>   4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1"
>  or similar for the custom target platorm.  Make sure that the
>  SONAME and symbol versions contain the "-opt" or "_OPT" tweak.

In reading the various README and INSTALL files, I'm not entirely clear on what 
this means.  I'm guessing:

1. During the build, the makefile ld flags have to include the variant -opt to 
get the right libraries to link.

2. Not at all clear on what the "_OPT" part means - do I need to change my 
source code to use this for accessors or ???

Thanks.

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

RE: Errors building 1.1.1 on RHEL 7

[Mark Richter]

-Original Message- [edited]
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Wednesday, July 17, 2019 6:17 PM
To: openssl-users@openssl.org
Subject: Re: Errors building 1.1.1 on RHEL 7

>>>   2. Configure your OpenSSL build to use the corresponding "rpath":
>>>  -Wl,-rpath,/opt/openssl/1.1/lib
>>>
> > Again, how do I specify that?
>
>Command-line argument to "Configure" or custom platform template.

Is Linux considered to be the same as (or similar enough to) Unix w.r.t. the 
building instructions?  I'm reading the INSTALL file and it doesn't mention 
Linux (nor are there templates for, etc.).

Also, once I figure out the build issues, how can I statically link the ssl 
libraries into my app?  (That way we don't require our customers to build and 
install OpenSSL 1.1.1 pon their RHEL 7 hosts.)  Are there any gotchas to doing 
this?  E.g., our app also uses the curl library, which I believe uses the 
default openssl on the host.

Thanks.

Mark

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

RE: Errors building 1.1.1 on RHEL 7

[Mark Richter]

I'm still really new at this - a few questions:

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Wednesday, July 17, 2019 12:42 PM
To: openssl-users@openssl.org
Subject: Re: Errors building 1.1.1 on RHEL 7

On a system with OpenSSL 1.0.2 or OpenSSL 1.1.0 in /usr/lib (on the default 
search path), and especially when you're linking with other libraries that in 
turn were linked against the OpenSSL version in /usr/lib, using OpenSSL
1.1.1 in your application requires care...

Specifically:

  1. Choose some location that is not on the default library search path
 to install the 1.1.1 custom libraries.  I use /opt/openssl/1.1/lib
> How do I specify that?  A config parameter (and which one)?

  2. Configure your OpenSSL build to use the corresponding "rpath":
 -Wl,-rpath,/opt/openssl/1.1/lib
> Again, how do I specify that?

  3. Add a custom target platform to the "targets" array in
 Configurations/.conf.  This can inherit from
 the configuration you're using now, but add a setting
 for "shlib_variant" as described in Configurations/README

...
inherit_from => "",
shlib_variant => "-opt",
...
> I can find that...

  4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1"
 or similar for the custom target platorm.  Make sure that the
 SONAME and symbol versions contain the "-opt" or "_OPT" tweak.
> Not familiar with that tweak.

  5. Link your application against this library:

-I/opt/openssl/1.1/include -L/opt/openssl/1.1/lib 
-Wl,-rpath,/opt/openssl/1.1/lib
> Can do.

  6.  Check with "readelf -d" that the application records the expected SONAME
  for the OpenSSL library (libcrypto and/or libssl) dependencies.
> Can do.

You can now have your code using OpenSSL 1.1.1 and other libraries you use, 
using whichever OpenSSL they were compiled with.  However, you cannot pass 
OpenSSL objects you create into such libraries, their use of OpenSSL must be 
self-contained.

--
Viktor.

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

RE: Errors building 1.1.1 on RHEL 7

[Mark Richter]

It works better with 1.1.1c.

Thank you.

-Original Message-
From: Matt Caswell 
Sent: Wednesday, July 17, 2019 1:16 AM
To: Mark Richter ; openssl-users@openssl.org
Subject: Re: Errors building 1.1.1 on RHEL 7



On 16/07/2019 23:27, Mark Richter wrote:
> Result: PASS

Well that's quite odd because this test was failing for you before. I assume 
that after you had done the "make clean" that "make test" is still failing? Is 
it failing with the same set of tests that were failing before or different 
ones?

Matt


> make[1]: Leaving directory `/tmp/openssl-1.1.1'
> [root@sfsdr220d openssl-1.1.1]# perl -v
>
> This is perl 5, version 16, subversion 3 (v5.16.3) built for
> x86_64-linux-thread-multi (with 33 registered patches, see perl -V for
> more detail)
>
> Copyright 1987-2012, Larry Wall
>
> Perl may be copied only under the terms of either the Artistic License
> or the GNU General Public License, which may be found in the Perl 5 source 
> kit.
>
> Complete documentation for Perl, including FAQ lists, should be found
> on this system using "man perl" or "perldoc perl".  If you have access
> to the Internet, point your browser at http://www.perl.org/, the Perl Home 
> Page.
>
>
> Mark Richter | Senior Staff Engineer
> SolarFlare Communications, Inc. | www.Solarflare.com
> 9444 Waples Street, #170, San Diego, CA  92121
> Mobile: +1 949-632-8403
>
>
> 
> From: openssl-users  on behalf of
> Matt Caswell 
> Sent: Tuesday, July 16, 2019 3:20 PM
> To: openssl-users@openssl.org
> Subject: Re: Errors building 1.1.1 on RHEL 7
>
> On 16/07/2019 22:23, Mark Richter wrote:
>> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 
>> 'make test.'  What do they mean?
>>
>>
>> Test Summary Report
>> ---
>> ../test/recipes/15-test_dsa.t(Wstat: 768 Tests: 6 
>> Failed: 3)
>>   Failed tests:  4-6
>>   Non-zero exit status: 3
>
> Looks like something fundamentally wrong to get this many errors
> (guess: perl version is too low?)
>
> Please run:
>
> make TESTS=test_dsa V=1 test
>
> Also lets see the output from:
>
> perl -v
>
> Matt
>
>
>> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 
>> Failed: 3)
>>   Failed tests:  3-5
>>   Non-zero exit status: 3
>> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 
>> Failed: 4)
>>   Failed tests:  2-5
>>   Non-zero exit status: 4
>> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 
>> Failed: 30)
>>   Failed tests:  2-31
>>   Non-zero exit status: 30
>> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 
>> Failed: 1)
>>   Failed test:  2
>>   Non-zero exit status: 1
>> ../test/recipes/15-test_rsa.t(Wstat: 768 Tests: 6 
>> Failed: 3)
>>   Failed tests:  4-6
>>   Non-zero exit status: 3
>> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 
>> Failed: 2)
>>   Failed tests:  1, 5
>>   Non-zero exit status: 2
>> ../test/recipes/20-test_enc.t(Wstat: 256 Tests: 87 
>> Failed: 1)
>>   Failed test:  2
>>   Non-zero exit status: 1
>>   Parse errors: Bad plan.  You planned 172 tests but ran 87.
>> ../test/recipes/20-test_enc_more.t   (Wstat: 256 Tests: 137 
>> Failed: 1)
>>   Failed test:  2
>>   Non-zero exit status: 1
>> ../test/recipes/25-test_crl.t(Wstat: 768 Tests: 7 
>> Failed: 3)
>>   Failed tests:  2, 6-7
>>   Non-zero exit status: 3
>> ../test/recipes/25-test_pkcs7.t  (Wstat: 512 Tests: 3 
>> Failed: 2)
>>   Failed tests:  2-3
>>   Non-zero exit status: 2
>> ../test/recipes/25-test_req.t(Wstat: 1024 Tests: 9 
>> Failed: 4)
>>   Failed tests:  2, 7-9
>>   Non-zero exit status: 4
>> ../test/recipes/25-test_sid.t(Wstat: 256 Tests: 2 
>> Failed: 1)
>>   Failed test:  2
>>   Non-zero exit status: 1
>> ../test/recipes/25-test_x509.t   (Wstat: 1792 Tests: 9 
>> Failed: 7)
>>   Failed tests:  2-8
>>   Non-zero exit status: 7
>> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 
>> Failed: 0)
>>   Non-zero exit status: 255
>>   Parse errors: Bad plan.  You planned 4 tests but ran 0.
>> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 
>> Failed: 0)
>>   Non-zero exit status: 255
>

RE: Errors building 1.1.1 on RHEL 7

[Mark Richter]

Hi Jan,

Thanks for that.  I got 1.1.1c and it built properly.

I configured it to use /usr/local/openssl for the target per the instructions 
on https://blacksaildivision.com/how-to-install-openssl-on-centos, and 
everything seemed to go well.  I get this:

11:02 [mrichter@sfsdr220d:~] $ openssl version
OpenSSL 1.1.1c  28 May 2019

After I log out and back in.

However, although I modified our make file to use 
'-I/usr/local/openssl/include' and '-L/usr/local/openssl/lib', I now see this 
warning:

cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ 
-D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 
(3bf2875895d5+ Wed Jul 17 11:14:55 PDT 2019)" -Isrc/include 
-I/usr/local/openssl/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include 
-Isrc/emulators/mbedtls/include -I/usr/include/json-c   -g3 
-fno-omit-frame-pointer build/src/tools/sfslc.o -o build/bin/sfslc -Lbuild/lib 
-L/usr/local/openssl/lib  -lsfsl_api -lsf_core -lcm -lss -lcrypto  -lpci -lcurl 
-lpthread -lrt -lssl -luuid -ljson-c
/usr/bin/ld: warning: libssl.so.10, needed by /usr/lib64/libssh2.so.1, may 
conflict with libssl.so.1.1
/usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may 
conflict with libcrypto.so.1.1

I tried googling this and get lots of suggestion for similar errors with 
libcurl, but not this one.

What am I missing?

-Original Message-
From: Jan Just Keijser 
Sent: Wednesday, July 17, 2019 2:53 AM
To: Mark Richter ; Matt Caswell ; 
openssl-users@openssl.org
Subject: Re: Errors building 1.1.1 on RHEL 7

FWIW:

I just downloaded openssl 1.1.1c, untarred it on my CentOS 7 box, then ran
   ./config
   make
   make test

The tests passed with the following output (the "ok" tests stripped out):

...
../test/recipes/05-test_md2.t .. skipped: md2 is not 
supported by this OpenSSL build ...
../test/recipes/05-test_rc5.t .. skipped: rc5 is not 
supported by this OpenSSL build ...
../test/recipes/30-test_afalg.t  skipped: test_afalg not 
supported for this build ...
../test/recipes/90-test_gost.t . skipped: No test GOST 
engine found ...
../test/recipes/90-test_overhead.t . skipped: Only supported in 
no-shared builds ...
../test/recipes/95-test_external_boringssl.t ... skipped: No external tests 
in this configuration ../test/recipes/95-test_external_krb5.t  
skipped: No external tests in this configuration 
../test/recipes/95-test_external_pyca.t  skipped: No external tests 
in this configuration ...
All tests successful.
Files=155, Tests=1452, 66 wallclock secs ( 1.44 usr  0.11 sys + 62.90 cusr 
13.51 csys = 77.96 CPU)
Result: PASS
make[1]: Leaving directory `/home/janjust/src/openssl-1.1.1c'


Share and enjoy,

JJK

On 17/07/19 00:27, Mark Richter wrote:
> I removed the directory, re-untarred the source, ran 'make clean', then 
> 'make', then 'make TESTS=test_dsa V=1 test':
>
> [root@sfsdr220d openssl-1.1.1]# make TESTS=test_dsa V=1 test make
> depend && make _tests
> make[1]: Entering directory `/tmp/openssl-1.1.1'
> make[1]: Leaving directory `/tmp/openssl-1.1.1'
> make[1]: Entering directory `/tmp/openssl-1.1.1'
> ( cd test; \
>mkdir -p test-runs; \
>SRCTOP=../. \
>BLDTOP=../. \
>RESULT_D=test-runs \
>PERL="/usr/bin/perl" \
>EXE_EXT= \
>OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \
>OPENSSL_DEBUG_MEMORY=on \
>  /usr/bin/perl .././test/run_tests.pl test_dsa )
> /tmp/openssl-1.1.1/test ../test/recipes/15-test_dsa.t ..
> 1..6
> ok 1 - require '../../test/recipes/tconversion.pl';
>  # Subtest: ../../test/dsatest
>  1..1
>  ok 1 - dsa_test
> ../../util/shlib_wrap.sh ../../test/dsatest => 0 ok 2 - running
> dsatest
>  # Subtest: ../../test/dsa_no_digest_size_test
>  1..3
>  ok 1 - dsa_exact_size_test
>  ok 2 - dsa_small_digest_test
>  ok 3 - dsa_large_digest_test
> ../../util/shlib_wrap.sh ../../test/dsa_no_digest_size_test => 0 ok 3
> - running dsa_no_digest_size_test
>  1..10
>  ok 1 - initializing
> read DSA key
> writing DSA key
> ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out 
> dsa-f.d -outform d => 0
>  ok 2 - p -> d
> read DSA key
> writing DSA key
> ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out 
> dsa-f.p -outform p => 0
>  ok 3 - p -> p
> read DSA key
> writing DSA key
> ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out 
> dsa-ff.dd -outform d => 0
>  ok 4 - d -> d
> read DSA key
> writing DSA key
> ../../util/shlib_wrap.sh ../../a

Re: Errors building 1.1.1 on RHEL 7

[Mark Richter]

./util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d 
-inform d -out msb-ff.dmsblob -outform msblob => 0
ok 11 - d -> msblob
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p 
-inform p -out msb-ff.pmsblob -outform msblob => 0
ok 12 - p -> msblob
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob 
-inform msblob -out msb-ff.msblobmsblob -outform msblob => 0
ok 13 - msblob -> msblob
ok 14 - comparing orig to p
ok 15 - comparing p to dp
ok 16 - comparing p to pp
ok 17 - comparing p to msblobp
ok 18 - comparing msblob to dmsblob
ok 19 - comparing msblob to pmsblob
ok 20 - comparing msblob to msblobmsblob
ok 6 - dsa conversions -- public key
ok
All tests successful.
Files=1, Tests=6,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.23 cusr  0.08 
csys =  0.33 CPU)
Result: PASS
make[1]: Leaving directory `/tmp/openssl-1.1.1'
[root@sfsdr220d openssl-1.1.1]# perl -v

This is perl 5, version 16, subversion 3 (v5.16.3) built for 
x86_64-linux-thread-multi
(with 33 registered patches, see perl -V for more detail)

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403



From: openssl-users  on behalf of Matt 
Caswell 
Sent: Tuesday, July 16, 2019 3:20 PM
To: openssl-users@openssl.org
Subject: Re: Errors building 1.1.1 on RHEL 7

On 16/07/2019 22:23, Mark Richter wrote:
> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 
> 'make test.'  What do they mean?
>
>
> Test Summary Report
> ---
> ../test/recipes/15-test_dsa.t(Wstat: 768 Tests: 6 Failed: 
> 3)
>   Failed tests:  4-6
>   Non-zero exit status: 3

Looks like something fundamentally wrong to get this many errors (guess: perl
version is too low?)

Please run:

make TESTS=test_dsa V=1 test

Also lets see the output from:

perl -v

Matt


> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 
> 3)
>   Failed tests:  3-5
>   Non-zero exit status: 3
> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 
> Failed: 4)
>   Failed tests:  2-5
>   Non-zero exit status: 4
> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 
> Failed: 30)
>   Failed tests:  2-31
>   Non-zero exit status: 30
> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 
> 1)
>   Failed test:  2
>   Non-zero exit status: 1
> ../test/recipes/15-test_rsa.t(Wstat: 768 Tests: 6 Failed: 
> 3)
>   Failed tests:  4-6
>   Non-zero exit status: 3
> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 
> 2)
>   Failed tests:  1, 5
>   Non-zero exit status: 2
> ../test/recipes/20-test_enc.t(Wstat: 256 Tests: 87 
> Failed: 1)
>   Failed test:  2
>   Non-zero exit status: 1
>   Parse errors: Bad plan.  You planned 172 tests but ran 87.
> ../test/recipes/20-test_enc_more.t   (Wstat: 256 Tests: 137 
> Failed: 1)
>   Failed test:  2
>   Non-zero exit status: 1
> ../test/recipes/25-test_crl.t(Wstat: 768 Tests: 7 Failed: 
> 3)
>   Failed tests:  2, 6-7
>   Non-zero exit status: 3
> ../test/recipes/25-test_pkcs7.t  (Wstat: 512 Tests: 3 Failed: 
> 2)
>   Failed tests:  2-3
>   Non-zero exit status: 2
> ../test/recipes/25-test_req.t(Wstat: 1024 Tests: 9 
> Failed: 4)
>   Failed tests:  2, 7-9
>   Non-zero exit status: 4
> ../test/recipes/25-test_sid.t(Wstat: 256 Tests: 2 Failed: 
> 1)
>   Failed test:  2
>   Non-zero exit status: 1
> ../test/recipes/25-test_x509.t   (Wstat: 1792 Tests: 9 
> Failed: 7)
>   Failed tests:  2-8
>   Non-zero exit status: 7
> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 
> Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 4 tests but ran 0.
> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 
> Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 3 tests but ran 0.
> ../test/recipes/80-test_ca.t   

Errors building 1.1.1 on RHEL 7

[Mark Richter]

After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 
'make test.'  What do they mean?


Test Summary Report
---
../test/recipes/15-test_dsa.t(Wstat: 768 Tests: 6 Failed: 3)
  Failed tests:  4-6
  Non-zero exit status: 3
../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3)
  Failed tests:  3-5
  Non-zero exit status: 3
../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 
4)
  Failed tests:  2-5
  Non-zero exit status: 4
../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 
30)
  Failed tests:  2-31
  Non-zero exit status: 30
../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
../test/recipes/15-test_rsa.t(Wstat: 768 Tests: 6 Failed: 3)
  Failed tests:  4-6
  Non-zero exit status: 3
../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2)
  Failed tests:  1, 5
  Non-zero exit status: 2
../test/recipes/20-test_enc.t(Wstat: 256 Tests: 87 Failed: 
1)
  Failed test:  2
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 172 tests but ran 87.
../test/recipes/20-test_enc_more.t   (Wstat: 256 Tests: 137 Failed: 
1)
  Failed test:  2
  Non-zero exit status: 1
../test/recipes/25-test_crl.t(Wstat: 768 Tests: 7 Failed: 3)
  Failed tests:  2, 6-7
  Non-zero exit status: 3
../test/recipes/25-test_pkcs7.t  (Wstat: 512 Tests: 3 Failed: 2)
  Failed tests:  2-3
  Non-zero exit status: 2
../test/recipes/25-test_req.t(Wstat: 1024 Tests: 9 Failed: 
4)
  Failed tests:  2, 7-9
  Non-zero exit status: 4
../test/recipes/25-test_sid.t(Wstat: 256 Tests: 2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
../test/recipes/25-test_x509.t   (Wstat: 1792 Tests: 9 Failed: 
7)
  Failed tests:  2-8
  Non-zero exit status: 7
../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 
0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 4 tests but ran 0.
../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 
0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
../test/recipes/80-test_cms.t(Wstat: 1024 Tests: 4 Failed: 
4)
  Failed tests:  1-4
  Non-zero exit status: 4
../test/recipes/80-test_ocsp.t   (Wstat: 512 Tests: 11 Failed: 
2)
  Failed tests:  1, 10
  Non-zero exit status: 2
../test/recipes/80-test_ssl_new.t(Wstat: 6912 Tests: 27 Failed: 
27)
  Failed tests:  1-27
  Non-zero exit status: 27
../test/recipes/80-test_ssl_old.t(Wstat: 1536 Tests: 6 Failed: 
6)
  Failed tests:  1-6
  Non-zero exit status: 6
../test/recipes/80-test_tsa.t(Wstat: 3328 Tests: 0 Failed: 
0)
  Non-zero exit status: 13
  Parse errors: Bad plan.  You planned 20 tests but ran 0.
../test/recipes/90-test_store.t  (Wstat: 3328 Tests: 0 Failed: 
0)
  Non-zero exit status: 13
  Parse errors: Bad plan.  You planned 209 tests but ran 0.
Files=152, Tests=850, 30 wallclock secs ( 0.38 usr  0.10 sys + 31.02 cusr  4.55 
csys = 36.05 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1'
make: *** [tests] Error 2

?


Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com<http://www.solarflare.com/>
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

Re: Drbg kat test data: Openssl-fips 2.0.16

[Mark Minnoch]

Manish asked:

> There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16)
> Can anyone let me know, What is the source of this constant arrays. NIST
> link or any other  source will be helpful?

I'm pretty sure that the test data for the DRBG KAT (known answer test)
came from the NIST algorithm test tool when the OpenSSL team tested all of
the algorithm implementations.

The CAVP also posts sample test vectors if you are looking for that sort of
thing:
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators#DRBG

Mark J. Minnoch
Co-Founder, CISSP
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*Blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*

error: dereferencing pointer to incomplete type DH {aka struct dh_st}

[Mark Richter]

I've tried looking this up on the web, but there is no cleare guidance on how 
to get around this.


I'm attempting to build our RHEL 7 based product on RHEL 8 and running into a 
lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 8).  I 
haven't found a good guide to adapting the sources to these changes.


Where can I find one?


Thanks.

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com<http://www.solarflare.com/>
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

[Ludwig, Mark]

Thanks, from someone else who builds no-shared and will need this mod.

From: openssl-users  On Behalf Of John 
Unsworth
Sent: Thursday, May 16, 2019 5:47 AM
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

In the absence of any steer from openssl gurus we will proceed by removing the 
#pragmas in safestack.h and lhash.h while we build the no-shared libraries on 
solaris. Hopefully someone will come up with a proper fix at some point.

Regards,
John

From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of John Unsworth
Sent: 15 May 2019 21:08
To: openssl-users@openssl.org
Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

>> Issue #pragma weak for a symbol only in the files that define that symbol, 
>> not in the ones that merely reference it.
The problem is that those pragmas are in .h files. They contain inline 
functions that use those symbols. The pragmas were added because of problems 
with apps that used the .h files (hard to avoid since they are basic crypto 
header files) but did not link with libcrypto.so. That library was explicitly 
loaded by the app, but the app would not start because of the missing symbols.

See issues 6912 and 8102.

Regards,
John.

-Original Message-
From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of Jakob Bohm via openssl-users
Sent: 15 May 2019 16:11
To: openssl-users@openssl.org
Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

Alternative suggestion (from my understanding of the documentation quoted
below):

Issue #pragma weak for a symbol only in the files that define that symbol, not 
in the ones that merely reference it.

The hoped effect would be:

1. Object files that merely reference a symbol will contain regular UNDEF
   entries
2. Object files that do define such a symbol will contain a WEAK defined
   entry
3. When seeing the UNDEF entries, the linker will look for an actual
   definition
4. If finding multiple WEAK defined entries, the linker will not complain,
   just use the first found.

I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" 
entries would be suitable for optional link-time selected callbacks or data 
where a referencing library do runtime tests to see if the library- using 
program has provided a definition or not.  For example, it could be used for a 
symbol holding a list of global C++ constructors/destructors with libc code 
invoking that list if present without requiring dummy lists in programs without.

The .so case mentioned probably works "by chance" because libssl.so references 
non-weak libcrypto.so symbols, forcing the definition to be included in the 
runtime process anyway.

On 14/05/2019 11:29, John Unsworth wrote:
> Because of the #pragma weak directive the functions are defined multiple 
> times in both libcrypto.a and libssl.a:
>
> libcrypto.a
>
> Many UNDEF:
> ct_log.o
> [47]|   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> ... and more
>
> One definition from stack.c as you'd expect:
> stack.o
> [33]  |1232|  20|FUNC |WEAK |2|2  
> |OPENSSL_sk_new_null
>
> libssl.a has multiple instances also, all UNDEF:
> d1_srtp.o
> [43]  |   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> s3_lib.o
> [107] |   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> and so on.
>
>  From the linker docs:
> B.2.17.1 #pragma weak name
> In the form #pragma weak name, the directive makes name a weak symbol. The 
> linker will not complain if it does not find a symbol definition for name. It 
> also does not complain about multiple weak definitions of the symbol. The 
> linker simply takes the first one it encounters.
>
> So when linking with libcrypto.a and libssl.a the first definition is taken 
> which is UNDEF in both cases leading to the error.
> This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o 
> the first files included. It could also be fixed by not defining those 
> pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then 
> be GLOB instead of WEAK and will override all the WEAK definitions.
>
> However there is no suitable fix for libssl.a because those files are not 
> part of that library.
>
> Doing that means that executables that link libcrypto.a before libssl.s are 
> built correctly. However if the link is libssl.a followed by libcrypto.a the 
> UNDEF symbols from libssl.a are still used.
>
> In the shared libraries I see:
>
> libcrypto.so only instance:
> [3537]| 2409672|  20|FUNC |LOCL |2|10 
> |OPENSSL_sk_new_null
>
> Shared libssl.so also one instance:
> [2091]|   0|   0|FUNC 

RE: Reg solaris support for openssl 1.1.1b

[Ludwig, Mark]

> From: Dennis Clarke, Friday, March 15, 2019 8:33 AM
> 
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> > My guess is that your binary is loading the system's shared libraries.
> > To find out whether this is the case, try
> >
> >     ldd bin/openssl
> >
> > If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> > explicitely.
> 
> Actually LD_LIBRARY_PATH is evil.
> 
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.

Assuming you are in control of the destination systems' library locations, 
RUNPATH is desirable.

For an ISV, LD_LIBRARY_PATH is a necessary evil for application-delivered 
libraries.

> Building on Solaris is a real pain.

Compared with what?  This is how all Unices/*nix's work.

Best,
Mark Ludwig

Re: [openssl-users] [openssl-project] OpenSSL 3.0 and FIPS Update

[Mark Minnoch]

Responding to some earlier questions:

> Can you give any guidance on which platforms will be validated with the
OpenSSL FIPS 3.0 module?  My recollection is that it will only be a handful
of platforms.

I would expect the number of platforms to be small. The wonderful 5
sponsors of the FIPS project will likely direct the initial platforms.

> Any additional information about how other platforms can be validated
would also be helpful.

My company, KeyPair Consulting, performs FIPS testing for new platforms for
the OpenSSL FOM 2.0. We plan to continue this service for the OpenSSL FIPS
Module for 3.0.

-- 
Mark J. Minnoch
Co-Founder, CISSP
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*Blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*

Re: [openssl-users] OpenSSL 3.0 and FIPS Update

[Ludwig, Mark]

+1 on the point: firm expiration date without firm replacement date ... really?!

We have to hope that the firm expiration date will actually move if the 
replacement isn't ready before then ... and that doesn't begin to account for 
the calendar time to get the new one certified

Thanks,
Mark Ludwig

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Jakob Bohm via openssl-users
Sent: Thursday, February 14, 2019 10:34 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 3.0 and FIPS Update

On 13/02/2019 20:12, Matt Caswell wrote:
>
> On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote:
>> On 13/02/2019 12:26, Matt Caswell wrote:
>>> Please see my blog post for an OpenSSL 3.0 and FIPS Update:
>>>
>>> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
>>>
>>> Matt
>> Given this announcement, a few questions arise:
>>
>> - How will a FIPS provider in the main tarball ensure compliance
>>   with the strict code delivery and non-change requirements of the
>>   CMVP (what was previously satisfied by distributing physical
>>   copies of the FIPS canister source code, and sites compiling this
>>   in a highly controlled environment to produce a golden canister)?
> My understanding is that physical distribution is no longer a requirement.
And the other things in that question?

Integrity of validated source code when other parts of the tarball
get regular changes?

Building the validated source code in a controlled environment
separate from the full tarball?

(If there are answers in the FIPS 3.0.0 draft spec, they need repeating).

>> - Will there be a reasonable transition period where users of the
>>   old FIPS-validated module can transition to the new module (meaning
>>   that both modules are validated and usable with a supported
>>   FIPS-capable OpenSSL library)?  I imagine that applications relying
>>   on the existing FIPS canister will need some time to quality test
>>   their code with all the API changes from OpenSSL 1.0.x to OpenSSL
>>   3.0.x .  OS distributions will also need some time to roll out the
>>   resulting feature updates to end users.
> The old FIPS module will remain validated for some time to come, so both the 
> old
> and new modules will be validated at the same time for a while. 1.0.2 will go
> EOL at the end of this year. The intention is that 3.0 will be available 
> before
> that. It's not yet clear exactly when 3.0 will become available and what the
> overlap with 1.0.2 will be so I don't have an answer at this stage for
> transition period.
>
> Matt
>
So right now, FIPS-validated users are left hanging, with no date to
get a 3.0.0 code drop to start porting and a looming deadline for the
1.0.x API.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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-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] Celebrating 20 Years of OpenSSL

[Mark J Cox]

Just about 20 years ago we released the first OpenSSL, but that wasn't the
original name for the project.

Read more in the blog post at
https://www.openssl.org/blog/blog/2018/12/20/20years/

Regards, Mark J Cox
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl 1.1.1 Cannot find fucntion

[Mark Shnaider via openssl-users]

Hello ,
I use openssl 1.1.1  and cannot find function :
 lh_X509_NAME_free, lh_X509_NAME_insert, lh_X509_NAME_retrieve referenced in 
function _SSL_load_client_CA_file in file ssl_cert.c
Please help me to solve this problem
Mark


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

[openssl-users] error: void value not ingored as it to be crypto/err/err_all.c

[Mark via openssl-users]

I'm trying to build OpenSSL with FIPS module in a centos docker container.  The 
FIPS module builds fine but the openssl build fails with:

_USE_NODELETE -MMD -MF crypto/err/err_all.d.tmp -MT crypto/err/err_all.o -c -o 
crypto/err/err_all.o crypto/err/err_all.c
crypto/err/err_all.c: In function 'err_load_crypto_strings_int':
crypto/err/err_all.c:47:9: error: void value not ignored as it ought to be
 FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata) == 0 ||
 ^
crypto/err/err_all.c:95:9: error: void value not ignored as it ought to be
 ERR_load_FIPS_strings() == 0 ||
 ^
make[1]: Leaving directory `/tmp/openssl-1.1.0i'

The relevant parts of my dockerfile are:

ENV PREFIX=/usr/local

ENV FIPSVER=2.0.16

ENV SSLVER=1.1.0i

ENV OPENSSLDIR=${PREFIX}/ssl

ENV FIPSDIR="${OPENSSLDIR}/fips-2.0"

ENV CFLAGS="-m64 -fPIC"

ENV LDFLAGS="-m64 -fPIC -L${PREFIX}/lib64"

ENV CC=gcc

ENV CXX=g++

ENV SSL_CONFIG="fips -DSSL_ALLOW_ADH -fPIC -I/usr/local/ssl/fips-2.0/include 
shared zlib"

# Custom FIPS enabled SSL

ADD ssl/openssl-fips-${FIPSVER}.tar.gz /tmp

WORKDIR /tmp/openssl-fips-${FIPSVER}

RUN ./config --prefix=${FIPSDIR}

RUN make

RUN make install

ADD ssl/openssl-${SSLVER}.tar.gz /tmp

WORKDIR /tmp/openssl-${SSLVER}

RUN ./Configure \

--prefix=${OPENSSLDIR}  \

--openssldir=${OPENSSLDIR}  \

${SSL_CONFIG} linux-x86_64

RUN make

RUN make test

RUN make install

Any help would be appreciated.
-Mark-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list()

[Mark H. Wood]

On Wed, Jul 18, 2018 at 03:24:31PM -0500, Ryan Beethe wrote:
> For a safe client application, should you explicitly set the cipher list
> explicitly, rather than trust the default cipher list that comes from
> the package manager's libssl?

I would say that the answer to that depends on another question:  do
you regularly review the package manager's default cipher list, and
have reason to trust it?

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

[Mark Minnoch]

I'm responding to a previous post about obtaining a CD of the OpenSSL FIPS
Object Module from KeyPair Consulting rather than directly from OpenSSL.
The question is:

> Just curious, but does this satisfy Section 6.6 of the User Guide,
> since the CD does not come directly from the OpenSSL Foundation?

That's a great question. KeyPair Consulting will send a copy of the OpenSSL
FOM on CD to people that choose not to use the following options:

The best way to get the OpenSSL FIPS Object Module distribution is directly
from OpenSSL at https://www.openssl.org/source/

The second best way is to get the OpenSSL FIPS Object Module CD directly
from OpenSSL (as described in the OpenSSL FOM Security Policy and User
Guide).

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL FIPS Object Module 2.0 on CD

[Mark Minnoch]

If you are looking for a copy of the OpenSSL FIPS Object Module (versions
2.0 to 2.0.16) delivered to you on CD, then please send an email to
c...@keypair.us with your shipping address.

We will send you a copy of the original OpenSSL FOM CD.

For details, see: https://keypair.us/2018/05/cd/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS 140-2 certification

[Mark Minnoch]

Oleg wrote:
> We would like to add to our product OpenSSL with FIPS 140-2 module. The
problem is that our OS
> and CPUs are not FIPS certified. We use vxWorks 5.5.1 with 3 types of
CPUs in different products.
>
> How can we get certification for these environments? OSF answered that
they do not do FIPS
> consulting work anymore. Can somebody explain what is the process and
cost to get such
> certification?

My company, KeyPair Consulting, helps our Clients with FIPS 140-2 testing
for the OpenSSL FIPS Object Module. I sent Oleg a direct message with
additional details. Our service is described here:
https://keypair.us/private-labels/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Test SSL connection

[Mark Shnaider via openssl-users]

Hello Walter,
I did not found  file ca.pem (root certificate) for testing.

Thanks
Mark

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Walter H.
Sent: Wednesday, May 30, 2018 11:17 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Test SSL connection

On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:

Hello,

I use  OpenSSL version is openssl-1.1.0h(Windows) and

I run following command from apps directory

openssl s_server -accept 443 -www

The server in this case use certificate "server.pem"

On client computer I run command

openssl s_client -connect 10.65.48.108:443

On client computer I  get error :

Verify return code: 21 (unable to verify the first certificate)

What is wrong?

Thanks for any help

Mark
very probable, that the client doesn't have the root ca certificate of the ca 
certificate that signed server.pem

you should have at least the following

ca.pem  - the root ca
server.pem - the server ssl/tls certificate

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

[openssl-users] Test SSL connection

[Mark Shnaider via openssl-users]

Hello,
I use  OpenSSL version is openssl-1.1.0h(Windows) and
I run following command from apps directory
openssl s_server -accept 443 -www
The server in this case use certificate "server.pem"
On client computer I run command
openssl s_client -connect 10.65.48.108:443
On client computer I  get error :
Verify return code: 21 (unable to verify the first certificate)
What is wrong?
Thanks for any help
Mark



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

Re: [openssl-users] ar : File format not recognized

[Ludwig, Mark]

> From: Bill Kurland, Tuesday, April 17, 2018 4:19 PM
> 
> I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of 
> building the IO::Socket::SSL perl module.
> 
> make fails when creating libcrypto.a and libssl.a because, it seems, the *.o 
> files are in a format not recognized by ar
> 
> I've passed "-Wl,-baix5coff64-rs6000" in config. I've also set 
> LDFLAGS="-Wl,-rpath=/usr/local/openssl/lib -Wl,-baix5coff64-rs6000" though I 
> don't see how that would have an effect on this problem.
> 
> I get the same result when I try to run ar command shown in the make output 
> from the command line:
> ar r ../test2.sh
> 
> where test2.sh contains all the *.o files in crypto
> 
> Every source I can find seems to indicate that gcc should just 'know' what 
> the correct file format is. Am I missing something? Well, obviously I'm 
> missing something. Can anyone point out what?
> 
> Thanks

Not sure this will help, because I built v1.0.2 (haven't gotten to v1.1.0 yet) 
using the AIX compiler rather than gcc, but the AIX archiver (ar) has a -X 
option that specifies how many bits.

For example, your example might work as:

 ar -X 64 r LIBNAME.a ../test2.sh

(At least, I assume you're building 64-bit binaries based on seeing "coff64" 
above.)
(I also assume you omitted the library name in e-mail.)

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

[openssl-users] FIPS Non?-Approved Cryptographic Functions

[Mark Minnoch]

> From the OpenSSL FIPS Security Policy chapter 4, it mentioned there are a
> number of non-FIPS approved algorithms/ services which are still
> implemented by the FIPS canister modules (e.g. RSA, DSA, DRDB, ECDSA etc).
>
> Just wondering why these algorithms are still implemented by FIPS
Canister.
>
> The concern is, if these algorithms could still be used under FIPS mode,
> there is risk that the applications which use the FIPS canister modules
may
> become non-FIPS compliant if these algorithms are used by mistake.

You are correct. It is possible for an application to use the OpenSSL FOM
in a non-approved way by calling a non-approved service listed in Table 4c
of the OpenSSL FOM Security Policy. I'm sure it was easier for the OpenSSL
team to make documentation changes (rather than making coding changes and
performing additional FIPS testing) to maintain the validity of the FIPS
certificate when the SP 800-131A transitions were enforced.

A coding change to the FIPS canister would require review by the FIPS
Laboratory. If any of the updates were found to be security relevant (from
a FIPS perspective), then a FIPS revalidation effort involving additional
testing would be required. As you know, there are many, many, many "Tested
Configurations" (operating systems+hardware platforms) listed for the
OpenSSL FOM certificates. A revalidation would result in a new OpenSSL FOM
FIPS certificate and all of the previously tested configurations (that
people care about) would need to be retested. Yikes.

Here is some background for those interested...
At the time of the original OpenSSL FOM validation, FIPS 140-2 allowed the
use of an ANS X9.31 RNG. Digital signature functions could be performed
using key sizes that provided an equivalent strength of 80 bits or greater.
With the transition timelines documented in SP 800-131A, FIPS modules today
must use only SP 800-90A DRBGs (for key generation) and >= 112 bits of
equivalent strength for digital signature functions (although digital
signature verification may be performed at previously allowed key sizes for
legacy purposes). The services provided by the OpenSSL FOM that do not meet
current SP 800-131A requirements are now listed as non-approved services in
Table 4c of the OpenSSL FOM Security Policy.

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
https://KeyPair.us
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
<https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 key wrapping transition

[Mark Minnoch]

The OpenSSL FOM Cert. #1747 will not be moved to the CMVP Historical List since 
it does not implement a non-compliant AES key wrapping service in the defined 
cryptographic boundary.

All of the FIPS modules that implement a non-compliant AES key wrapping service 
have already been moved to the Historical List.

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting Inc.
+1 (805) 550-3231 mobile
https://KeyPair.us <https://keypair.us/>
https://www.linkedin.com/in/minnoch
 <https://www.linkedin.com/in/minnoch>
We expertly guide technology companies in achieving their FIPS goals






signature.asc
Description: Message signed with OpenPGP
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Fwd: Simplifying the security policy

[Mark J Cox]

At our face to face we took a look at the security policy and noticed
that it contained a lot of background details of why we decided on the
policy that we did (in light mostly of the issues back in 2014) as
well as a bit of repeated and redundant information.  We've taken some
time to simplify it, clean it up, and remove the redundant sections
with the intention of not changing any of the actual policy.   This passed
an OMC vote and is now updated here:

https://www.openssl.org/policies/secpolicy.html

Also as a reminder, last week we also explained a slight increase in the
pre-disclosure time: https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

Detailed changes:
- removed introductory wordy paragraphs
- how to report issues is already covered on another page so just
replace with link
- consolidate who we tell about issues into new 'triage' section (it
was in 3 different places) explain why we work with those folks
- take out most of the background section.  Where the background forms
part of our reasons for doing something include them in a new section
'principles' at the end with the same wording.
-- removed "the more people you tell" leak statement
-- consolidated how we benefit from prenotifying people into earlier section
-- removed competitive phrases
-- removed why we don't run our own prenotification list and who we've
tired to use in the past
- no changes to severity wording
- simplify prenotification section wording without changing what we do
or who we tell

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

Re: [openssl-users] FIPS certification for openssl

[Mark Minnoch]

If you need a FIPS resource for the OpenSSL FIPS Object Module -- my
business partner (Steve Weymann) and I worked with Steve Marquess when we
were at a FIPS Testing Lab to achieve the FIPS 140-2 Cert. #1747 for the
OpenSSL FIPS Object Module.

We are now helping technology companies that need FIPS testing of the
OpenSSL FOM on specific operating systems. We also perform Private Label
validations to rebrand the OpenSSL FOM for our clients.

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
https://KeyPair.us
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help compiling on HPUX

[Ludwig, Mark]

> From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Help compiling on HPUX
> 
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Dan Freed
> > Sent: Tuesday, November 07, 2017 19:14
> > To: openssl-users@openssl.org
> > Subject: [openssl-users] Help compiling on HPUX
> 
> > I see that there are a few posts about compiling openssl on HP-UX, so I’m
> hopeful that someone can help me out.
> 
> My initial suspect is the assembly modules. I suggest configuring with no-asm,
> and if that works and you really want the assembly code for performance, then
> investigate further.
> 
> Another possibility is optimization. We had issues building OpenSSL for HP-UX
> (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least
> some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually
> use our own Configure script, and merge in changes from the official one each
> time we update to a new OpenSSL release).

Dan, you did not specify the platform.  I have not built on RISC since OpenSSL 
0.9.8.
I have built OpenSSL 1.0.2k on Itanium as follows.  I mostly agree with 
Michael, 
but have not backed off optimization quite as far.  Note that my use cases do 
not
include encrypting/decrypting large payloads, so can get away with reduced
performance to get correct results (i.e., pass the tests).

I had to edit util/selftest.pl for the compiler's identification output
and because the ar(1) command will not accept /dev/null as an input file.

I also eliminated a lot of the tests in test/cms-tests, because we do not use 
the 
modules being tested.  (They were failing.)  I can believe these might work 
with 
lower optimization such as Michael recommends.

Below is the Configure output.  Hope this helps.

Configuring for hpux64-ia64-cc
no-asm  [option]   OPENSSL_NO_ASM
no-dso  [option]  
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-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=0
CC=cc
CFLAG =+Z -DOPENSSL_PIC -DOPENSSL_THREADS  -Ae +DD64 +O3 +Olit=all -z 
-DB_ENDIAN -D_REENTRANT
EX_LIBS   =-ldl
CPUID_OBJ =mem_clr.o
BN_ASM=bn_asm.o
EC_ASM=
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_core.o aes_cbc.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/ccs/bin/ranlib
ARFLAGS   =
PERL  =/usr/local/smd/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_RISC1 used
DES_UNROLL used
DES_INT used
RC4_INDEX mode
RC4_CHUNK is undefined
MD2 uses uchar

> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> --
> 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] More on cert serialnumbers

[Mark H. Wood]

On Thu, Aug 17, 2017 at 03:29:56PM +, Erwann Abalea via openssl-users wrote:
> The BR are for public CAs, not private CAs; even if some of those 
> requirements are considered « good practice » (the 64 bits out of a CSPRNG is 
> such a req), they cannot be forced on private CAs.
> And unless some or all of the browsers also apply these requirements to 
> private CAs, you’re not forced to follow them all.

How does one mechanically distinguish public vs. private CAs?

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] newer openSSL no longer produce libeay32 on Windows?

[Ludwig, Mark]

> From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM
> 
> On 08/06/2017 18:48, Baojun Wang wrote:
> > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well
> > as libcrypto-1_1-x64.dll, this could be painful for application who
> > has to specify openssl dependency, for example now I have to choose
> > ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a
> > more idiomatic way to make linking on windows (not only 64-bit)
> > easier, do you have any idea?
> Traditionally, Windows (like Unix) uses the same file name for
> 32 and 64 bits, but puts them in different directories.  If
> they need to be in the same directory for some applications,
> the traditional solution is to insert "32" or "64" on its own,
> while still using the same file name for different architectures
> with the same bitness.  For example a compile for 32 bit MIPS
> (supported by older Windows releases) or 32 bit ARM (supported
> by newer releases) would have the same name as for 32 bit x86.
> Similar for the 4 64 bit architectures supported at various
> times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM).
> 
> Microsoft did some crazy experiments with a directory scheme
> called SxS for versioned DLLs, its badly done and should be
> avoided if possible.

The side-by-side (SxS) stuff has its place, but to use it
effectively requires using a "manifest" to identify the
dependencies explicitly.  I also don't recommend it for
general use.

Regarding the "32" suffix, you'll see that throughout
Windows itself, on modern 64-bit versions, because the "32"
dates back to the 1990s when Windows was trying to grow out
of being a 16-bit DOS program (WIN.EXE) into a 32-bit
"operating system" (Windows NT).  Many people are
misdirected with the term "Win32" into thinking that means
32-bit when it really only means "not 16-bit."  Anything
labeled "Win32" could be either 32-bit or 64-bit.

I haven't started working with OpenSSL 1.1.n, but in OpenSSL
1.0.2, all 64-bit builds produce identically-named binaries
such as libeay32.lib and libeay32.dll in the "out32"
directory.

Hope this helps,
Mark

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Mark H. Wood]

On Thu, Jun 01, 2017 at 09:18:26PM -0400, Viktor Dukhovni wrote:
> 
> > On Jun 1, 2017, at 10:54 AM, Wouter Verhelst  
> > wrote:
> > 
> > It might be useful to make that point at the start of the CHANGES file,
> > then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
> > [date]". While that doesn't claim to be complete, the simple word
> > "CHANGES" invokes the idea of a changelog, which should be complete --
> > and this file is not. If it's not meant to be, fine -- but then it
> > doesn't hurt to say so, and it would alleviate some confusion.
> 
> Sure, would "Major changes" be sufficient?  This is essentially
> a RELEASE_NOTES file, not a comprehensive change log, which is
> subsumed by git.

Exactly.  Lots of us have been trained by much experience that a file
named CHANGES contains *all* of the changes, while a file named
RELEASE_NOTES includes selected changes of particular significance.
It's confusing to call a release-notes file CHANGES.

Appending a note that, for a full change log, [DO THIS], would probably
be well received.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Return type of SSL_ctrl

[Ludwig, Mark]

> From: Jeremy Farrell, Wednesday, November 30, 2016 12:25 PM

> Some confusion here. SSL_ctrl() was defined as returning long in 0.9.8a, and 
> from what (little) I can see it looks like it was that way back in 0.6.4.

Right, I was confused by looking in derived internal source.
I had no idea we had modified it to change the return type from long to int.  
(*Shrug*)

Thanks,
Mark

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

Re: [openssl-users] Return type of SSL_ctrl

[Ludwig, Mark]

> From: Salz, Rich, Wednesday, November 30, 2016 9:38 AM
> 
> > We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and
> > noticed that the SSL functions based on SSL_ctrl() changed from returning
> > type int to returning type long.
> 
> The "proper" answer is to not use long, but rather sized types, which we are
> slowly moving toward.

Funny you should mention this, because this topic arose
internally after someone decided to change the return type
of SSL_ctrl() to intprt_t.  I have no idea why, since as far
as I can tell, all of the return values would fit in a
32-bit integer; thus my question about why it was changed to
long, which is either 32 bits or 64 bits, depending on
platform.  I suspect it was the use of long that tricked someone 
into thinking it might be holding a pointer, and thus led to the 
change to intptr_t, so it would fit on Windows.  (Blind/stupid
global replacement.)

(Does OpenSSL support any platform in which type int is 16 bits?)

Thanks,
Mark

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

[openssl-users] Return type of SSL_ctrl

[Ludwig, Mark]

Greetings,

We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and noticed 
that the SSL 
functions based on SSL_ctrl() changed from returning type int to returning type 
long.

It's not clear why this is necessary, by spot-checking the documented numerical 
domain of the 
return values of the SSL functions (macros) deriving from SSL_ctrl().  Why was 
this done?

(I don't see mention of this in the CHANGES file.)

Thanks,

Mark Ludwig

Siemens Product Lifecycle Management Software Inc.
Communications and Government Affairs
Product Lifecycle Management
Lifecycle Coll
5939 Rice Creek Parkway
Shoreview, MN  55126 United States 
Tel.  :+1 (651) 855-6140
Fax  :+1 (651) 855-6280
ludwig.m...@siemens.com 
www.siemens.com/plm 

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

Re: [openssl-users] Any advice/recommendation for watching TLS version negotiation

[Ludwig, Mark]

> From: Wall, Stephen, Monday, November 28, 2016 6:52 AM
> 
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> > Behalf Of Ludwig, Mark
> >
> > A customer claims to have configured the web (app) server to only allow
> > TLS 1.2
> > (by disallowing up through TLS 1.1), and says that the client code
> > (which we
> > know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS
> > 1.1.  We
> > are setting up a similar environment internally to diagnose what's
> > happening,
> > and I wonder if anyone has any advice on the "best" tool for "watching"
> > the TLS
> > version negotiation when the connection is being established.
> 
> I've typically used Wireshark for this type of thing.  If you are using RSA 
> and have
> a copy of the server key, you can also examine the encrypted channel content.

Yes, thanks, a colleague today enlightened me that Wireshark will read the 
captured data from snoop.  Voila!

I didn't bother to get the key -- not sure it's RSA -- because I'm not 
interested 
in the encrypted data.  I only want to see the TLS handshake, which Wireshark 
decodes nicely.

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

[openssl-users] Any advice/recommendation for watching TLS version negotiation

[Ludwig, Mark]

Greetings,

We have embedded OpenSSL 1.0.2j in our application order to securely
communicate with a Java Servlet engine (such as Tomcat).  Our application uses
SSLv23_method(), so I expect it to negotiate up through TLS 1.2 (right?).

A customer claims to have configured the web (app) server to only allow TLS 1.2
(by disallowing up through TLS 1.1), and says that the client code (which we
know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS 1.1.  We
are setting up a similar environment internally to diagnose what's happening,
and I wonder if anyone has any advice on the "best" tool for "watching" the TLS
version negotiation when the connection is being established.

The client environment is Solaris 10.  I'm obtaining the necessary privileges
to use the snoop command.  Does anyone have any do's or don'ts for using snoop?

Thanks in advance!

Mark Ludwig

Siemens Product Lifecycle Management Software Inc.
Communications and Government Affairs
Product Lifecycle Management
Lifecycle Coll
5939 Rice Creek Parkway
Shoreview, MN  55126 United States 
Tel.  :+1 (651) 855-6140
Fax  :+1 (651) 855-6280
ludwig.m...@siemens.com 
www.siemens.com/plm 

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

[openssl-users] Forthcoming OpenSSL releases

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2g, 1.0.1s.

These releases will be made available on 1st March 2016 between approximately
1300-1700 UTC.  They will fix several security defects with maximum severity
"high".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.1
will end on 31st December 2016.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWzsjbAAoJEAEKUEB8TIy9ukoH/A+KQh0TPuC5CulMeFd4OiGy
7HV9bX/nCe4sKmW5IGYt6GDPFRnhup9WR9Dvz0C/sBjwttsnF+UZOUUfYbDw2liO
YG46kiS95zbeU4yYFQwHr9Sf01o89ogEGrxCIlKQiA4aXSZwn9liI0a51y7izWUC
xdj2GEgQ/fnVnlN/AyToVmoQxlrphXJx9FigLxTuXi1X6nvSNdEYB1VtOuqjanRu
8sR4UDCWYRZNT0L3as0IEU49X7ncwm5a85NR02SkVimevdbJw0mBT1ru4Zjddo88
oO5xpgSKy2a56xC8yQXURkVPvuFqUpfvyojLwOULUnWHCpnDhzn+ygdko2Pii3o=
=XURc
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2

[Mark Parr]

Thanks, Rich.

That fixed things.  Obviously not familiar w/ memmove() or the memcpy() issue 
w/ overlapping data area.

Thanks again.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: Tuesday, February 09, 2016 2:44 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 
13.2


   // Generates Garbage
   memcpy(encbuf, encbuf+100, enclen); 

For overlapping copies you are supposed to use memmove.

-- 
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 library/development problems on OpenSUSE 13.2

[Mark Parr]

I have a program that for some time now under SUSE Linux Enterprise Server has 
worked fine.  Recently, it was moved over to an OpenSUSE 13.2 system and a 
problem was encountered.  The program interfaces to a 3rd party  and data is 
received into our program where the data block consists of some header 
information and AES encrypted data.  Using the OpenSSL libcrypto library we 
successfully interfaced to this system under SLES.  However, under OpenSUSE we 
consistently see the an error where the end of the decrypted data contains 
garbage.  I have identified where the problem happens and have a work around 
but in looking at the code, I don’t see why there would be a problem.

 

I have created a test program that simulates the problem.  The test program 
works fine under SUSE Linux Enterprise Server 11 and on a Red Hat 7.2 
Enterprise Linux but fails on OpenSUSE 13.2 using different release levels of 
the OpenSSL libraries.  Under SLES and Red Hat, the decrypted data is cleanly 
returned.  Under OpenSUSE, most of the data is decrypted cleanly except for 
some garbage that appears toward the end of the data block.  The returned block 
of data is correct, then contains some garbage, and then ends correct.  The 
code for my sample program is below but the line causing the problem is a 
memcpy() where I shift the encrypted data to the front of the data block for 
processing.  The line in my sample program is below:

 

   // Generates Garbage

   memcpy(encbuf, encbuf+100, enclen); 

 

If I move the encrypted data to temporary buffer before moving it to the start 
of the encbuf, the garbage is not generated.

 

   // This does not generate garbage

   memcpy(tmpbuf, encbuf+100, enclen); 

   memcpy(encbuf, tmpbuf, enclen); 

 

My sample program takes a defined buffer of clear text, encrypts it using a key 
and IV and then decrypts it back and displays the result.  Condensed code is as 
follows:

 

#include   

#include  

#include  

#include  

#include

#include   

#include   



#include 



#define EVP_DECRYPT   0 

#define EVP_ENCRYPT   1

 

char clrbuf[10];

char encbuf[10];

char tmpbuf[10];

int clrlen; 

int enclen; 

 

char enckey[1024];  

unsigned char enciv[16];

 

main()

{

   int rc;

 

   // Set clear text to 50 lines of text

   sprintf(clrbuf,   

 "0001this is a test this is a test this is a test this is a test\n" \

 "0002this is a test this is a test this is a test this is a test\n" \

 "0003this is a test this is a test this is a test this is a test\n" \

 // etc etc etc…….

 "0048this is a test this is a test this is a test this is a test\n" \

 "0049this is a test this is a test this is a test this is a test\n" \

 "0050this is a test this is a test this is a test this is a test\n"  

 

   sprintf(enckey, "this is the key this is the key ");

   sprintf(enciv, "1234567890123456");

 

   // Encrypt the data and simulate a 100 byte header by returning encrypted 
data 100 bytes into the data block

   //

   memcpy(encbuf, "Some header stuff that will need to be removed", 46);

   rc = evp_aes256_cbc(clrbuf, strlen(clrbuf), encbuf+100, &enclen, enckey, 
enciv, EVP_ENCRYPT);  

 

   // Now remove the header by shifting the encrypted data to the start of the 
data block and decrypt

   // This is where doing the memcpy() as coded in OpenSUSE results in garbage 
at the end of clrbuf

   // but everything is returned correctly in SLES and Red Hat

   //

   // This work fines on all OSes:

   // memcpy(tmpbuf, encbuf+100, enclen); 

   // memcpy(encbuf, tmpbuf, enclen); 

 

   memcpy(encbuf, encbuf+100, enclen); 

   rc = evp_aes256_cbc(encbuf, enclen, clrbuf, &clrlen, enckey, enciv, 
EVP_DECRYPT);

 

   printf("Decrypt: rc=%d  EncLen=%d  ClrLen=%d\n", rc, enclen, clrlen);

   printf("Data:\n\n<\n%s\n>\n\n", clrbuf); 
}

 

//  



evp_aes256_cbc(char *InBuf, int InLen, char *OutBuf, int OutLen, char *Key, 
char *IV, int EncryptFlag)  

{   

   EVP_CIPHER_CTX ctx;  

   int padlen;  



   EVP_CIPHER_CTX_init(&ctx);   



   if (! EVP_CipherInit_ex(

[openssl-users] Forthcoming OpenSSL releases

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2f, 1.0.1r.

These releases will be made available on 28th January between approx.  1pm and
5pm (UTC). They will fix two security defects, one of "high" severity affecting
1.0.2 releases, and one "low" severity affecting all releases.

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.0 and
0.9.8 releases ended on 31st December 2015 and are no longer receiving security
updates.  Support for 1.0.1 will end on 31st December 2016.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWpgNkAAoJEAEKUEB8TIy9QcwH/3C7y700FjGjDBcNMcVO++GU
81cs87VqsoziuMSU9Sx8XlDWA8tH5JWXpES4+p9iWdKbks+2E0EahVZVaS5yDaLM
LY6MaUM2Pucmrd/I7mvQ02AzzMWEUrFlbk1GtFVjU7IkYc1/ZOZLhjM6H0X8M8lO
5kvqpgWTGV5lMCJdOQLr/eIGIdGTy5Xqerm3Qz/nzvhbwaOu5pjvq0eub8AWbPb3
wwdB4GIKW4XaU7YAJl61o8jNeVoy/kMTfZmZYEefQzXf/1JYO2p8oqCMTIEUrSoN
P7sT2d2DpjQvrK3j8MsIPMYUHLhxZt+MJ2+wuOLyznkPTdEIV+ylr6q0I74Wv1Q=
=gzHe
-END PGP SIGNATURE-
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Mark H. Wood]

With regard to the idea that one can simply make older algorithms
Somebody Else's Problem:  is it *known* that another viable,
well-maintained product sees this as one of its roles?  That would be
more reassuring, I think, than just hoping that some unknown group
will step into the gap.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


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

Re: [openssl-users] FIPS OpenSSL Test Harness and RSA PSS

[Mark]

We have moved to just using Salt 0 for now but would like to get some help
with the Salt Len 62 issues. Does anyone have any special instructions for
this?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-Test-Harness-and-RSA-PSS-tp60789p60798.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Forthcoming OpenSSL releases

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2d and 1.0.1p.

These releases will be made available on 9th July. They will fix a
single security defect classified as "high" severity.  This defect does
not affect the 1.0.0 or 0.9.8 releases.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz
Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM
2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW
e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w
HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP
NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ=
=yVBV
-END PGP SIGNATURE-








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

[openssl-users] [openssl-announce] Forthcoming OpenSSL releases

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2d and 1.0.1p.

These releases will be made available on 9th July. They will fix a
single security defect classified as "high" severity.  This defect does
not affect the 1.0.0 or 0.9.8 releases.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz
Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM
2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW
e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w
HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP
NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ=
=yVBV
-END PGP SIGNATURE-








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

Re: [openssl-users] Generating FIPS Compliant libcrypto.so

[Mark]

Ok, the API call was not correct RSA_generate_key_ex was not working same. I
have resolved all the issues now.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890p58904.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Generating FIPS Compliant libcrypto.so

[Mark]

Ok, I will answer my own question here. The problem was that I did not have
the LD_LIBRARY_PATH set correctly for openssl.




--
View this message in context: 
http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890p58899.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Generating FIPS Compliant libcrypto.so

[Mark]

Ok, I searched and there are a lot of topics around building the fip
compliant version of openssl. My problem is with the generation of the
libcrypto.so.

Environment
Debian 8
openssl fips 2.0.9
openssl 1.0.1o

I follow the security guide and build a valid fipscanister.o file. I test it
and it works fine.

Then in section 3.3 of the users guide it states.
"The FIPS Object Module is not directly usable as a shared library, but it
can be linked into an
application that is a shared library. A “FIPS compatible” OpenSSL
distribution will automatically
incorporate an available FIPS Object Module into the libcrypto shared
library when built using
the fips option (see §4.2.3)."

Then in section 4.2.3 of the users guide it states.
"Once the validated FIPS Object Module has been generated it is usually
combined with an
OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1
release can be
used for this purpose. The commands

  ./config fips <...other options...>
  make <...options...>
  make install

will build and install the new OpenSSL without overwriting the validated
FIPS Object Module
files."

This produces a version of libcrypto.a that can be statically linked to an
application and SET_FIPS_MODE(1); Returns 1. However, this does process does
not create the libcrypto.so file during the build process. 

So my next logical step was to configure openssl-1.0.1o for shared
libraries. 

   ./config fips shared
make depend
make
su root
make install

This creates libcrypto.so just fine. However here is the rub, i get the
following issue trying to link the functions into a file.
140261525202608:error:0F06D065:common libcrypto routines:FIPS_mode_set:fips
mode not supported:o_fips.c:92:


I am also having an issue where openssl 1.0.1o creates PEM version of the
public/private keys = 
-BEGIN RSA PUBLIC KEY-
MAA=
-END RSA PUBLIC KEY-
-BEGIN PRIVATE KEY-
MBkCAQAwDQYJKoZIhvcNAQEBBQAEBTADAgEA
-END PRIVATE KEY-
-BEGIN RSA PUBLIC KEY-

no matter what size key i ask it to create 1024, 2048, or 4096 on the
statically liked version of the software.

What is the right way to get openssl to generate the libcrypto.so in a
"compliant" manner?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes

[Mark]

Ok, I finally figure out my issues. I was setting the environment variables
when I should not have been. The "make depend" set will setup all the fips
dependencies you need. So I was shooting myself in the foot so to speak.
Using the commands listed in the Security Policy for OpenSSL worked fine
once I ran them without the environment variables. Everything is working
fine now. Thanks for the help.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58762.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] fipsld linker out of control forking, last step of build

[Mark]

MAY BE REPOSTING TRYING TO MOVE FROM NABBLE TO OFFICIAL OPENSSL POSTINGI was 
wondering if someone has seen this issue before. I am guessing the problem is 
on my side because  can replicate it on Debian 8 and Ubuntu 14.4. I am using 
OpenSSL 1.0.2c and the crypto module from OpenSSL ecp 2.0.9 env settings 
CC=/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld 
FIPSLD_CC=/usr/bin/gcc FIPSDIR=/usr/local/ssl/fips-2.0 for building fips 
canister ./config fipscanisterbuild no-asm make make install using ./config 
fips no-asm make make install This seemed to be pretty straight forward. I 
think i created the fipscanister.o correctly. Everything compiled and linked 
for the canister. I liked it to a small test app that worked. I then tried to 
build openssl, it fine but on the last linking step the linker just keep 
forking processes out of control on both OSs until i got a message that the 
linker cannot fork any new processes. Any pointers would be appreciated. 
/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: 174: 
/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: Cannot fork 
../Makefile.shared:164: recipe for target 'link_app.' failed make[2]: *** 
[link_app.] Error 2 make[2]: Leaving directory 
'/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:153: recipe for 
target 'openssl' failed make[1]: *** [openssl] Error 2 make[1]: Leaving 
directory '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:285: 
recipe for target 'build_apps' failed make: *** [build_apps] Error 1 
myssluser@debian8:~/workspace/libs/openssl-1.0.2a$  
   ___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Linux Foundation Core Infrastructure Initiative fellowships

[Mark H. Wood]

\applause all around!

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature

Re: SSL Root CA and Intermediate CA Certs.

[Mark H. Wood]

On Thu, Apr 24, 2014 at 12:57:36PM +, Michael Wojcik wrote:
[snip]
> > How and why do you trust any root certs?  Generally they're built-in to your
> > OS or your browser, so you're just blindly trusting that those guys know 
> > what
> > they're doing.
> 
> And they don't, and they don't care that they don't. The SSL/TLS 
> X.509-with-well-known-CAs PKI is fundamentally broken and frequently 
> compromised. But there's little we can do about it, so we pretend it isn't.

Well, there certainly is something we can do about it, but you won't
like it any more than I do:

1.  Empty all of your trust stores.
2.  Add the cert.s of all CAs you already trust (if any) to your
trust stores.
3.  Investigate each CA you don't yet trust.  As you come to trust
one, add it to your trust stores.
4.  Pay attention to the CAs you trust, and evict any that seem to
have declined to a degree that worries you.
5.  Goto 3.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature

Re: ssh-add refuses to use the key on my USB thumb drive

[Mark H. Wood]

Or 'mount -o umask=077' I think.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature

ssh-add refuses to use the key on my USB thumb drive

[Mark Jason Dominus]

This is because the thumb drive is a vfat device, which has a very limited
permissions model.  The permissions of every file, as reported by the
device driver, are always 0644, and there is no escape.  When I try to add
the identity from the key file, ssh-add says:

@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE!  @
@@@
Permissions 0644 for '/media/USB20FD/.ssh/id_dsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Which is not really correct for this case.  To read the file, you still
have to possess the actual thumb drive. This is more secure than a file on
a shared or networked system with mode 0600.

I could work around this by copying the key file from the thumb drive to
the local computer, which defeats the whole purpose.

Short of rewriting the device driver, what can I do?

My system is:

Linux ortolan 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

RE: Error 18: self signed certificate

[Mark Currie]

Thank you for your advice. SSL_CTX_get_cert_store() was the right clue and
X509_STORE_add_cert() did the trick.

> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Dave Thompson
> Sent: 19 November 2013 00:07
> To: openssl-users@openssl.org
> Subject: RE: Error 18: self signed certificate
> 
> > From: owner-openssl-users On Behalf Of Mark Currie
> > Sent: Monday, November 18, 2013 03:24
> 
> > I also managed to get self-signed certs to work like this but does
> > anyone know how to use self-signed certs in a RAM-only environment
> > i.e. no disk available?
> >
> Your OS or C runtime might provide a RAM filesystem in which case you can
> use that, assuming you have the cert(s) to put in it. Otherwise as I said
> earlier, build SSL_CTX cert_store by hand, ditto.
> 
> Both these assume you have some permanent storage, maybe FLASH or even
> ROM. Presumably the program comes from somewhere secure, so at worst
> you can embed the cert data in your program, either as plain C data or as
> something like a 'resource' in Windows or MacOS.
> 
> > > -Original Message-
> > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> > > us...@openssl.org] On Behalf Of Manoj
> > > Sent: 18 November 2013 10:09
> > > To: openssl-users@openssl.org
> > > Subject: Re: Error 18: self signed certificate
> > >
> > > Thanks Guys for the help, I got it working by loading the location
> > > using
> > API
> > > SSL_CTX_load_verify_locations(). The location where I have the
> certificate
> > > available.
> > >
> > > I have another question related to certification verification itself.
> > > Can by any mean, I verify a peer certificate(self signed) without
> > > having
> > it in
> > > the trust-store?
> > >  or
> > > Let me put in other words , Server application verifiying clients
> > > with
> > each
> > > client having its own self signed certificate, Does the server
> > > require
> any
> > prior
> > > information about certificates (i.e. having them as part of cert
> > > trust
> > store)?
> > >
> For OpenSSL to do the verification it must have cert in truststore, yes.
> (To be exact it must have the root; for selfsigned the root is the cert.)
> 
> You can override or replace OpenSSL's verification using the callback(s),
but
> what will you use instead? There's nothing in a selfsigned cert by itself
> (without a truststore) that can't be faked. Instead of full certs you
could
> configure the peer=client publickey values and accept any cert using that
> value -- assuming handshake succeeds through Finished which also proves
> client possession of the privatekey.
> That's what ssh does, with a shortcut for configuration on first use.
> You could configure hashes of the publickeys -- even with MD5 and probably
> SHA1 broken for collision AFAIK there's no 2nd-preimage.
> You could configure hashes of the certs -- ditto -- although that would
make
> it harder to debug cases where a client created multiple certs for the
same
> key -- perhaps one by mistake and a corrected one -- and one of you has
the
> wrong one.
> 
> If you have more than a few authenticated clients, it is usually easier to
issue
> them certs under a CA -- either your own ad-hoc CA, which can be done with
> OpenSSL, or a 'real' public or organization CA -- and the server then only
> needs that one cert. Note if you use a CA that issues EE certs under an
> intermediate or "chain" cert -- which (all?) public ones do now --
according to
> standard the client should be configured to send the chain certs. However
> OpenSSL relier will fill in missing chain certs from its truststore, so it
may be
> easier to just configure them once on the server.
> 
> > > Or
> > > Is there any way possible of getting peer certificate without having
> > > set
> > the
> > > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> > >
> For *server* to get *client* cert, you must set SSL_VERIFY_PEER. It's your
> choice whether to use a callback or not (you can set it null). For
> *some* clients you may also need to call _set_client_CA_list to tell the
client
> which cert you want when it has more than one, but for simple OpenSSL
> clients they just use the one (per kx) configured cert&key without
checking if
> it matches the server request.
> 
> For *client* to get *server* cert you don't actua

RE: Error 18: self signed certificate

[Mark Currie]

Hi

I also managed to get self-signed certs to work like this but does anyone
know how to use self-signed certs in a RAM-only environment i.e. no disk
available?

> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Manoj
> Sent: 18 November 2013 10:09
> To: openssl-users@openssl.org
> Subject: Re: Error 18: self signed certificate
> 
> Thanks Guys for the help, I got it working by loading the location using
API
> SSL_CTX_load_verify_locations(). The location where I have the certificate
> available.
> 
> I have another question related to certification verification itself.
> Can by any mean, I verify a peer certificate(self signed) without having
it in
> the trust-store?
>  or
> Let me put in other words , Server application verifiying clients with
each
> client having its own self signed certificate, Does the server require any
prior
> information about certificates (i.e. having them as part of cert trust
store)?
> 
> Or
> Is there any way possible of getting peer certificate without having set
the
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> 
> Regards
> Manoj
> 
> 
> 
> --
> View this message in context: http://openssl.6102.n7.nabble.com/Error-18-
> self-signed-certificate-tp47361p47388.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

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

Re: 1.0.0e decryption failed or bad record mac

[Mark Pietras]

I take that back, there was a modification... we recently switched cipher 
preferences due to security concerns... might this have an impact on the issue??

SSL_CTX_set_options( ssl_ctx_server, SSL_OP_CIPHER_SERVER_PREFERENCE );


Mark.




- Original Message -
From: Mark Pietras 
To: "openssl-users@openssl.org" 
Cc: 
Sent: Thursday, August 15, 2013 1:45 PM
Subject: 1.0.0e decryption failed or bad record mac

Recently (within last month or so but can't pinpoint it to a specific change of 
ours in the OpenSSL version), we started getting this error:

error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac


We haven't changed our application in a way that changes the utilization of 
OpenSSL (although timing-related differences could certainly have an impact).  
We did some searching and see a lot of discussion regarding this.

Some recent (2013) search results indicate a seemingly related issue fixed in 
1.0.0e, however that's the version I'm on.

Some other results indicate this patch is related: 
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247 but the 
patch seems to be (just) prior to 1.0.0e, it's not clear to me

Information on my specific issue: it's not a connect-time or handshake-related 
issue... in my case, the connection is ongoing and this randomly shows up when 
there's a burst in traffic on the connection (sometimes minutes or hours into 
the connection).

Anyone have any additional insight before I dig deeper?  Thanks!  Mark.
__
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-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

1.0.0e decryption failed or bad record mac

[Mark Pietras]

Recently (within last month or so but can't pinpoint it to a specific change of 
ours in the OpenSSL version), we started getting this error:

error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac


We haven't changed our application in a way that changes the utilization of 
OpenSSL (although timing-related differences could certainly have an impact).  
We did some searching and see a lot of discussion regarding this.

Some recent (2013) search results indicate a seemingly related issue fixed in 
1.0.0e, however that's the version I'm on.

Some other results indicate this patch is related: 
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247 but the 
patch seems to be (just) prior to 1.0.0e, it's not clear to me

Information on my specific issue: it's not a connect-time or handshake-related 
issue... in my case, the connection is ongoing and this randomly shows up when 
there's a burst in traffic on the connection (sometimes minutes or hours into 
the connection).

Anyone have any additional insight before I dig deeper?  Thanks!  Mark.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CCM and GCM modes for Camellia?

[Mark Currie]

I meant this question to be WRT EVP support i.e. will EVP ever support
EVP_camellia_256_ctr() and EVP_camellia_256_gcm()?

Markc

> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Mark Currie
> Sent: 21 July 2013 11:48
> To: openssl-users@openssl.org
> Subject: CCM and GCM modes for Camellia?
> 
> Hi,
> 
> I know there is probably not much demand for it, but are there any plans
to
> add CCM and GCM modes for Camellia?
> 
> Markc
> 
> __
> 
> 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

CCM and GCM modes for Camellia?

[Mark Currie]

Hi,

I know there is probably not much demand for it, but are there any plans to
add CCM and GCM modes for Camellia?

Markc

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

Is it possible to choose your preferred cipher at the command line level?

[Mark Seger]

I'm running a tool via a python library that uses ssl and would like
to use a different cipher other than the one being negotiated.  Is it
possible to do this via an env variable or some config change on my
workstation, perhaps a config file?
-mark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: I can't believe how much this sucks

[Mark H. Wood]

On Tue, Nov 13, 2012 at 07:51:24PM +0100, "Magosányi, Árpád" wrote:
> On 11/13/2012 07:34 PM, Sanford Staab wrote:
> >
> > Do you guys just want to continue to answer questions on this alias
> > and not FIX the docs somewhat over time?  I could go into a litany of
> > how much information is just missing from the docs with INCOMPLETE
> > everywhere.
> 
> You might have overlooked the fact that openssl is an open source
> project. Feel free to contribute the needed documentation or finance the
> creation thereof if your knowledge is lacking to do so.

I've read more variations of this than I can count, and I never know
whether to laugh or cry when I read the assertion that the person with
the most imperfect understanding of the product is the best to tell
everyone how it works.  I've been that person and I know better.

> (Yes, the documentation is lacking, an I (r=1 user of openssl) also find
> this a sad state of affairs. But I find whining about a problem in an
> open source project in this tone disturbing. Rule of thumb: the more you
> contribute you have more right to whine. You and me have right to point
> out a bug, or respectfully ask for a feature.

Well, I've also been in the position of the person who *is* best
qualified to write documentation:  the author of the software.  In
that role, I would hope that people complain (with details) when I've
left something out.  And if I continue to leave it out, I would hope
that someone would show his respect for my skills with a good sharp
poke:  Mark, I know you can do better than this!

Reporting documentation problems is different from reporting software
problems.  In the latter case we send a report because we understand
(to some extent) what is wrong; in the former, often we only
understand that there is something missing but we have no idea what it
may be.  Our contribution is notice of the fact that someone read X
and did not find the knowledge he needed to use the product.  It could
(and should) extend to willingness to work with the writer to ensure
that the coverage and clarity of the writing is substantially
improved.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.


pgpNJNzqoTBIj.pgp
Description: PGP signature

Re: Best practice for client cert name checking

[Mark H. Wood]

On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote:
> try searching for "certificate pinning". If you are familiar with ssh, it
> is the same concept of the StrictHostKeyChecking option (although
> obviously SSH and TLS are completely distinct protocols and by default SSH
> doesn't use X.509 certs).
> 
> The idea is: with a standard TLS connection, acting as TLS client, you
> connect to an host for the first time and you receive its certificate. The
> standard TLS verifications are successful (meaning: the certificate really
> belongs to the host and it has been issued by a CA you trust). When the
> connection is closed, a normal TLS client will forget the certificate.
> 
> On the other hand, certificate pinning remembers the certificate. Pinning
> means storing locally such certificate and associate it to the hostname
> you connected to. If the next time you connect the certificate has
> changed, a system supporting certificate pinning will warn you.

I believe this is what the Certificate Patrol plugin for Firefox is
doing, if you want to see it in action.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.


pgpbBheOvp6Xv.pgp
Description: PGP signature

Re: Certificate and Certificate request (Using API)

[Mark H. Wood]

On Fri, Jul 27, 2012 at 08:05:58AM -0700, Sanford Staab wrote:
> It really looks to me like the openssl documentation needs improvement as 
> well as a better tool besides CA.pl to help people use openssl in common 
> scenarios.   I suspect there is a strong demand for creative private CA 
> support and we should have a friendly script or cookbook for this available 
> somewhere.  Fixing this will relieve you guys of answering all these 
> inquiries via email.

TinyCA has, so far, sufficed for my modest needs.
http://tinyca.sm-zone.net/

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.


pgpOYxbnU7YZ2.pgp
Description: PGP signature

Are there plans for the GCM to be supported in openssl 1.0 releases?

[Davis, Mark H]

I see that lots of work supporting the new TLS 1.2 GCM based ciphers are in 
openSSL 1.0.1  releases, but no indications in the open 1.0.0 releases.
Are there any plans to support these ciphers in the openssl 1.0.0 releases or 
is the plan to make openssl 1.0.1 the only release branch with this 
functionality?

Mark H. Davis
630.627.3027

intel accel engine and EVP_VerifyFinal

[Mark Mc Keown]

Hi All,
  I have built and installed intel-accel engine from
http://www.openssl.org/contrib.

When I use the engine to verify a certificate I get an error - I don't
get the error without
the engine.

mmk@mmk:~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010

mmk@mmk:~$ openssl verify -CAfile /tmp/certs/ca.crt /tmp/certs/s3peer.crt
/tmp/certs/s3peer.crt: OK

mmk@mmk:~$ openssl verify -CAfile /tmp/certs/ca.crt -engine
intel-accel  /tmp/certs/s3peer.crt
engine "intel-accel" set.
/tmp/certs/s3peer.crt:
/C=US/ST=CA/L=SanFrancisco/O=www.cloudopt.com/OU=cloudoptimizer/CN=cloudoptimizer-s3peer/name=cloudoptimizer-s3peer/emailAddress=supp...@cloudopt.com
error 7 at 0 depth lookup:certificate signature failure
11681:error:0606C06E:digital envelope routines:EVP_VerifyFinal:wrong
public key type:p_verify.c:85:
11681:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:173:


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

pkcs7 verification with ruby

[Mark Corner]

I have a pkcs7 message that contains a chain of certificates.  The
root certificate is the Apple CA.  I am using ruby to verify the
message and I have something that I think works, but I am wondering if
there is a much easier method of doing what I am doing

My specific question is in regards to OpenSSL::PKCS7::NOVERIFY which I
am using to verify the message internally.  The message passes this
verification, but I want to verify all the certificates trace back to
a real root CA.  So I added a loop to check each of the certificates
included and store them in an X509 store if they pass verification.  I
seed the store with the Apple root CA.

However, if I try to verify the pkcs7 message without
OpenSSL::PKCS7::NOVERIFY, even with the store containing all of the
certs, it fails.  I must be doing something dumb here, but
unfortunately the ruby openssl docs are terrible to non-existant.

#!/bin/ruby

require 'rubygems'
require 'openssl'
require 'plist'
signed_response_data=''

#wget http://www.apple.com/appleca/AppleIncRootCertificate.cer
#openssl x509 -inform der -in AppleIncRootCertificate.cer -out certificate.pem

store = OpenSSL::X509::Store.new

cert=OpenSSL::X509::Certificate.new(File.read("certificate.pem"))
store.add_cert(cert)

File.open('sign.dat', 'r') {|f| signed_response_data=f.read() }

p7sign = OpenSSL::PKCS7.new(signed_response_data)
puts p7sign.verify(nil, store, nil, OpenSSL::PKCS7::NOVERIFY)  # This
outputs true, but I am not verifying the certificates

# This works
p7sign.certificates.reverse.each{|c|
  if store.verify(c)
store.add_cert(c)
  else
raise("fail")
  end
}

puts p7sign.verify(nil, store, nil) #this outputs false.  Why?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: RE: Open SSL API's Support For IPv6.

[Mark . Itzcovitz]

Initialization code means code that runs before any other SSL code, not once 
you've already got an error.


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Akanksha Shukla
Sent: 31 October 2011 20:27
To: openssl-users@openssl.org; carlyo...@keycomm.co.uk
Subject: RE: RE: Open SSL API's Support For IPv6.

Hi,

I am sorry if I misunderstood things. I went through the text quoted by him.
Also, I did google search for that and what I understood was:
ERR_load_crypto_strings() registers the error strings for all libcrypto 
functions. SSL_load_error_strings() does the same, but also registers the 
libssl error strings. One of these functions should be called before generating 
textual error messages. However, this is not required when memory usage is an 
issue. ERR_free_strings() frees all previously loaded error strings.

So, I thought by calling SSL_load_error_strings() will register the SSL error 
strings automatically and once that is done, then probably SSL error string 
will get dumped in file. 

This is what I understood and also I am not much familiar with SSl API's.
So, here it might be possible that I mis-interpreted things.

Thanks
Akanksha Shukla.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeremy Farrell
Sent: Tuesday, November 01, 2011 1:39 AM
To: openssl-users@openssl.org; carlyo...@keycomm.co.uk
Subject: RE: RE: Open SSL API's Support For IPv6.

> From: Akanksha Shukla [mailto:akshu...@cisco.com]
> 
> Hi Carl,
> 
> I added the API's call as mentioned by you in the else part to get the 
> dump of the error. But this time also, I am not successful.
>   else
>   {
>  SSL_load_error_strings();
>  SSL_library_init();
>  FILE * pFile1;
>  pFile1 = fopen ("result.txt","a");
>  if (pFile1!=NULL)
>  {
> ERR_print_errors_fp(pFile1);
> fclose(pFile1);
>  }
>  cout << " The Bio_do_connect failed" << endl;
>  break;
>   }
> 
> This time also, I got blank file without having any output in it. Am 
> is missing something here or using them in incorrect way?
> 
> Please suggest.
> 
> Thanks
> Akanksha Shukla.
> 
> -Original Message-
> From: carlyo...@keycomm.co.uk [mailto:carlyo...@keycomm.co.uk]
> 
> > On Mon 31/10/11 4:25 PM , "Akanksha Shukla" akshu...@cisco.com sent:
> > Hi Michael,
> >
> > Thanks for the reply. But I think the issue is not from the C
> perspective.
> > As I already mentioned, that if I use fputs to directly write a
> string to
> > file, then I am able to do that successfully. But when I try to 
> > write
> the
> > error code thrown by Bio_do_connect() API, then nothing is getting
> written
> > in file and for that I have used the API suggested by Stephen in the
> forum
> > (ERR_print_errors_fp(pFile)).
> 
> Are you loading the strings?
> 
> From:http://www.openssl.org/docs/ssl/SSL_library_init.htmlEXAMPLES
> 
> A typical TLS/SSL application will start with the library 
> initialization, and provide readable error messages.
> SSL_load_error_strings();/* readable error
> messages
> */
> SSL_library_init();  /* initialize library
> */
> 
> Carl

Did you read the page he referred you to? Did you read the text he quoted?
Did you think about what it said at all?
__
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

The information in this message is intended solely for the addressee and should 
be considered confidential.  Publishing Technology does not accept legal 
responsibility for the contents of this message and any statements contained 
herein which do not relate to the official business of Publishing Technology 
are neither given nor endorsed by Publishing Technology and are those of the 
individual and not of Publishing Technology. This message has been scanned for 
viruses using the most current and reliable tools available and Publishing 
Technology excludes all liability related to any viruses that might exist in 
any attachment or which may have been acquired in transit.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager

Re: How to recover Self signed SSL private Key Pass Phrase

[Mark Ridley]

It was one of my family members
birthday written backwards followed by the word TeaPot with some
combination of upper
and lower case

Password of the year! :)

On 19 Oct, 2011, at 10:16 PM, Jakob Bohm  wrote:

> It was one of my family members
> birthday written backwards followed by the word TeaPot with some combination 
> of upper
> and lower case"
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org