Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
On 9/25/20 8:55 AM, Viktor Dukhovni wrote: > Well, I expected you to post a working and non-workin trace for the > *same* server endpoint, with the good and bad configuration. > > Secondly, (snip) > Where's the recording of the successful transmission to port 465 (and > not say 587). you asked for a capture of the _failed_ transaction. > For further progress a PCAP file is needed which contains a > full capture of exactly one TCP connection corresponding to this > failure. > You need to post A PCAP file that tshark can read with a single > TCP session containing the failed handshake. you did not ask for captures of BOTH failed & successful transactions. i'll pass on the drama. again, thx anyway.
Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
On 9/25/20 12:18 AM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 09:26:26PM -0700, PGNet Dev wrote: > I must lodge a complaint on wasting my time here seems your're done, then. thx anyway. > you intimated that just changing openssl.cnf makes the difference. i didn't 'intimate'. i stated so. as that is exactly/only what's changed. and the change it causes has been documented. > But that is clearly not the case, because you're testing different server > endpoints, with port > 60465 for the "working" case, and "465" for the non-working case. that's simply not the case as stated 60465 is the dovecot submission port 465 it the postfix submission port the mua submits to dovecot at port 60465 dovecot resubmits to postfix at port 465 that same configuration is used in each/every test. again, the ONLY thing that changed between the 'working' and 'failed' cases is the setting in openssl.cnf I never directly submit to 465 > It seems likely that you don't have TLS wrapper mode on port 60465. port 60465 is, and always has been, configured for implicit SSL -- not starttls usage.
Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
On 9/24/20 9:13 PM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 08:30:35PM -0700, PGNet Dev wrote: > Is that really the session you intended to capture. Interestingly phrased! The intention was to capture the tcp data 'thru' the failed event. That^^ is the data streamed to console, with that^^ tshark command, from right before the moment I exec the msmtp send, until it fails ... and sits there. Whether that tshark cmd correctly captures that 'intention', well that's a different issue. > It is surprising that the client sent "QUIT" only .14 seconds after SYN, > since if it expected to do SMTP STARTLS, it would typically wait for the > server greeting for more than a fraction of a second. So, iiuc, that's a dovecot faux pas? I certainly don't supsect that it's the result of anything that postfix signals in the transaction. If it's 'from' dovecot, how would I ferret out whether it's dovecot code "innards", or something in the (mis)function of linked openssl libs?
Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
On 9/24/20 7:32 PM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 06:43:05PM -0700, PGNet Dev wrote: > >> Been awhile since I 'de-noised' a comms dump; I'll dust off my notes, & work >> on getting a useful/relevant PCAP file ... > > # tcpdump -s0 -w /some/file tcp port 12345 thx, was already rattling around in the docs! > for notes on using "tshark" to extract the detailed protocol > diagnostics. These can be somewhat disappointing with TLS 1.3, > because privacy...(most of the handshake is encrypted). useful read > Looking at the upstream OpenSSL source, the first thing to note is that > the prefer chacha setting has no effect at all, unless you also have > server preference set (which you can do with Postfix settings, rather > than globally in the config file). i've tried with both tls_preempt_cipherlist = yes enabling postfix's cipher-suite prefs and with tls_preempt_cipherlist = no which iiuc uses the openssl.cnf 'global' setting > Secondly, the effect of "prefer chacha" is to just synthesize a > transient ordered list of server cipher preferences that moves any > cha-cha ciphers to the top, cipher selection then continues as usual. yup, that's one goal ... use chacha whenever available. > So your reported symptoms re protocol version mismatch look rather > perplexing, don't know what the client is doing, and whether the client > is even linked with OpenSSL? Is dovecot using OpenSSL or GnuTLS? dovecot's using openssl. it's used by default, https://wiki2.dovecot.org/CompilingSource#SSL.2FTLS_Support unclear if gnutls is supported still. in any case, the pkgs are built with openssl, https://src.fedoraproject.org/rpms/dovecot/blob/master/f/dovecot.spec#_155 now to the tcpdump ... for this instance with dovecot --version 2.3.10.1 (a3d0e1171) postconf mail_version mail_version = 3.5.7 openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 dovecot submission port == 60465 postfix submission port == 465 & cat /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] !! Options = ServerPreference,PrioritizeChaCha submitting the 'failed' (as above) message cat ~/test.eml | msmtp -a internal testrecipi...@example.com with this tshark cmd, tshark -n -V -i lo -d tcp.port==465,tls or -d tcp.port==60465,tls which i think does the trick?, the dump of dissected tls packets from both submission ports, is here: https://is.gd/d5R67s
Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
On 9/24/20 5:51 PM, Viktor Dukhovni wrote: >> again, the _only_ change between the two submissions is the addition of the >> "ServerPreference" option to the openssl.cnf config. > > This looks like the protocol version is no longer TLS 1.3 as a result, > and one side or the other now expects or sent the wrong protocol > version. For further progress a PCAP file is needed which contains a > full capture of exactly one TCP connection corresponding to this > failure. > > You need to post A PCAP file that tshark can read with a single > TCP session containing the failed handshake. Been awhile since I 'de-noised' a comms dump; I'll dust off my notes, & work on getting a useful/relevant PCAP file ... > You should check for any other non-default Postfix TLS settings that > may have been set to poorly chosen values. i need to re-read, again, to figure out what those might be, and what restrictions exist. iiuc, i _should_ be able to lock this all down to specification and use of even a _single_ cipher. it's all/only 'internal' (to my org) transport after all. i can certainly live with a short list -- but with the goal to 'always' end up using TLS13 chacha20-poly1305 suite . >> still not clear to me which piece(s) of that^ are having an issue with it. >> or why. > > Ultimately, the TLS library (OpenSSL) is failing to interoperate between > client and server after this change. But whether this is a bug in > OpenSSL, or a problem setting in the application is not yet clear. > >> for this list, my initial question is -- *IS* it openssl's "fault"? >> or mine, or one of the other apps'? > > What are the exact OpenSSL versons on the client and server? > Anything interesting in openssl.cnf on the client end? The client/server are the _same_ host. Specifically, dovecot & postfix are submission listeners on the same box -- on different ports, of course. So they both 'experience' the same openssl.cnf Version is openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 provided by distro pacakges on Fedora 32, rpm -qa | grep ssl | sort openssl-1.1.1g-1.fc32.x86_64 openssl-devel-1.1.1g-1.fc32.x86_64 openssl-libs-1.1.1g-1.fc32.x86_64
Re: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
> I'd be tempted to drop most if not all of those settings, they're not > email-friendly. PUBLIC email non-friendly, because of still-frequent old cipher/protocol implementations? or, inherently problematic with TLS in/onr SMTP? in this case, there's nothing public ... both the dovecot and postfix instances are internal. the internal postfix instance hands off to a public facing external postfix instance, which exposes/uses postfix-default cipherlists only. the attempt is to clean- & tighten-up the comms internally; not that that's particularly relevant to the error(s) seen. > That's rather more verbose than default Postfix TLS logging, I hope it is > temporary. yep. 'temporarily' monkeying with log levels all over the place, trying to find the cause of this^. now dialed back. > Are you sure the third line is copied correctly into your post? not entirely; it's copied from my too-busy/very-messy 'WTF?' notes. below, i've (re)included logs instead _directly_ copied from shell. > That cipherlist, has an extra "T" in front of the TLS 1.3 ChaCha cipher, that > should not be there... fat thumbs in notes, I suspect. > Also, Postfix has no knowledge of TLS 1.3 cipher suites, Postfix has only > cipher configuration knobs only for the TLS <= 1.2 ciphers, so I don't know > how that particular string ended up in your logs. a bit too postfix-y for this list, but ... I'm then perhaps misreading http://www.postfix.org/TLS_README.html http://www.postfix.org/FORWARD_SECRECY_README.html "If you want to take maximal advantage of ciphers that offer forward secrecy see the Getting started section of FORWARD_SECRECY_README. The full document conveniently presents all information about Postfix forward secrecy support in one place: what forward secrecy is, how to tweak settings, and what you can expect to see when Postfix uses ciphers with forward secrecy. Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later allows TLS servers to preempt the TLS client's cipher-suite preference list. This is possible only with SSLv3 and later, as in SSLv2 the client chooses the cipher-suite from a list supplied by the server. By default, the OpenSSL server selects the client's most preferred cipher-suite that the server supports. With SSLv3 and later, the server may choose its own most preferred cipher-suite that is supported (offered) by the client. Setting "tls_preempt_cipherlist = yes" enables server cipher-suite preferences. The default OpenSSL behavior applies with "tls_preempt_cipherlist = no". " RE-(re-,re-,etc-)reading, I'm now scratching my head a bit as to which is the server defining the preferences ... my _goal_ was to ensure that the server receiving submission -- 1st @ the MUA -> dovecot listener, then @ dovecot -> postfix -- dictates the ciphers/suites in use. or at least declares preference. In any case, the following should be with defaults. > Is there something in your Postfix configuration that resembles that particular blob? If so, it should not be there... yep. now removed ... with postfix's tls log level dialed back down -o smtpd_tls_loglevel=1 and its tls_high_cipherlist back to default simplifying /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] Options = PrioritizeChaCha @ test submit to dovecot cat ~/test.eml | msmtp -a internal testrecipi...@example.com send/receive is successful. dovecot logs 2020-09-24 04:59:01 submission-login: Info: Login: user=, method=PLAIN, rip=10.0.1.17, lip=10.0.1.17, mpid=11209, TLS 2020-09-24 04:59:01 submission(testrecipi...@example.com): Info: Successfully relayed message: from=, size=135, id=kROCNiWmbF/JKwAA+IOfAw, nrcpt=1, reply=`250 2.0.0 Ok: queued as 4BxxVF6VD2zWf49' 2020-09-24 04:59:01 lmtp(11200): Info: Connect from local 2020-09-24 04:59:01 submission(testrecipi...@example.com): Info: Disconnect from 10.0.1.17: Client has quit the connection in=223 out=114 (state=READY) 2020-09-24 04:59:02 lmtp(testrecipi...@example.com): Info: sieve: msgid=<4bxxvf6vd2zw...@mx.example.com>: stored mail into mailbox 'INBOX' 2020-09-24 04:59:02 lmtp(11200): Info: Disconnect from local: Client has quit the connection (state=READY) postfix logs Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: connect from internal.mx.example.com[10.0.1.17] Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: Trusted TLS connection established from internal.mx.example.com[10.0.1.17]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ?
i've got two servers communicating over ssl. comms between them work if /etc/pki/tls/openssl.cnf includes Options = PrioritizeChaCha but fail if 'ServerPreference' (cref: Undocumented openssl.cnf options and PrioritizeChaCha https://blog.germancoding.com/2020/05/30/undocumented-openssl-cnf-options-and-prioritizechacha/ man SSL_CONF_cmd ServerPreference: use server and not client preference order when determining which cipher suite, signature algorithm or elliptic curve to use for an incoming connection. Equivalent to SSL_OP_CIPHER_SERVER_PREFERENCE. Only used by servers. ) is added, Options = ServerPreference,PrioritizeChaCha i'm trying to understand expected behavior, and troubleshoot the 2 servers are postconf mail_version mail_version = 3.5.7 dovecot --version 2.3.10.1 (a3d0e1171) they're on the same machine, which runs grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 dovecot's configured to listen for SMTP submissions on its own submission proxy port 60465 dovecot then re-submits the message to postfix, on submission port 465. the openssl cnf containts /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] MinProtocol = TLSv1.2 CipherString = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 Ciphersuites = TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 Options = PrioritizeChaCha with that^^ config, message submit cat ~/test.eml | msmtp -a internal testrecipi...@example.net to dovecot:60465 succeeds. postfix logs report no probs, Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: connect from internal.mx.example.com[10.0.1.50] Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: Trusted TLS connection established from internal.mx.example.com[10.0.1.50]: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384 Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: 4BxVWX41svzWf7g: client=internal.mx.example.com[10.0.1.50] Sep 23 13:43:36 mx postfix/qmgr[27295]: 4BxVWX41svzWf7g: from=, size=583, nrcpt=1 (queue active) Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: disconnect from internal.mx.example.com[10.0.1.50] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Sep 23 13:43:36 mx postfix/lmtp[27329]: 4BxVWX41svzWf7g: to=, relay=mx.example.com[private/dovecot-lmtp], delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 kPB/Iniza1/YaQAA+IOfAw Saved) Sep 23 13:43:36 mx postfix/qmgr[27295]: 4BxVWX41svzWf7g: removed and the message _is_ delivered to final destination without error. mail flows -- in- & out-bound -- without interruption. OTOH, if, as mentioned above, I simply change - Options = PrioritizeChaCha + Options = ServerPreference,PrioritizeChaCha , then otherwise-identical submission to dovecot:60465 fails, cat ~/test.eml | msmtp -a internal testrecipi...@example.net msmtp: envelope from address testsen...@example.com not accepted by the server msmtp: server message: 421 4.4.0 internal.mx.example.com Failed to establish relay connection msmtp: could not send mail (account internal from /etc/msmtprc) and in postfix logs, Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: connect from internal.mx.example.com[10.0.1.50] Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: setting up TLS connection from internal.mx.example.com[10.0.1.50] Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: internal.mx.example.com[10.0.1.50]: TLS cipher list "TTLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:!aNULL" Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:before SSL initialization Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:error in error Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept error from
Re: matching openssl's enc ciphers to php's openssl functions' ciphers: where's "chacha20-poly1305"?
On 8/13/20 3:03 PM, Thomas Dwyer III wrote: > I think you want "openssl ciphers" rather than "openssl enc -ciphers". Per > the "enc" man page: > > The enc program does not support authenticated encryption modes like > CCM and GCM, and will not support such modes in the future. > > chacha20-poly1305 is an authenticated cipher. OpenSSL supports it but the enc > command line utility does not. got it. thx!
matching openssl's enc ciphers to php's openssl functions' ciphers: where's "chacha20-poly1305"?
I'm deploying a php app that makes use of php's openssl functions https://www.php.net/manual/en/ref.openssl.php atm, I've php -v PHP 7.4.8 (cli) (built: Jul 9 2020 08:57:23) ( NTS ) openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 The php app config defaults to an encryption method of $config['cipher_method'] = 'DES-EDE3-CBC'; for encrypting a session pwd, This key is used to encrypt the users imap password which is stored in the session record. I'd like to change that to a CHACHA20 variant. As listed by https://www.php.net/manual/en/function.openssl-get-cipher-methods.php the list of php-supported openssl ciphers includes [92] => chacha20 [93] => chacha20-poly1305 double checking available encryption ciphers @ openssl openssl enc -ciphers only lists -chacha20 not the add'l, -chacha20-poly1305 why is this^^ variant not shown? am I comparing apples & oranges here, looking at the wrong lists? perhaps just aliases for a singular cipher?
Re: cipherlist with only tlsv1.3 ciphers reports error?
On 7/20/19 8:17 AM, Viktor Dukhovni wrote: On Sat, Jul 20, 2019 at 07:35:49AM -0700, PGNet Dev wrote: Checking cipherlist for just TLSv1.3 ciphers FAILs here, openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list This is expected. Try: openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' TLS 1.3 cipher code points are fundamentally different from TLS 1.0–1.2 Thanks, mostly clear now. You've just not read the documentation carefully. You're possibly making some not-necessarily valid assumptions about who's read what, with what level of 'care', and the clarity of the written documents ...
Re: cipherlist with only tlsv1.3 ciphers reports error?
Hi, On 7/20/19 7:28 AM, Viktor Dukhovni wrote: > On Fri, Jul 19, 2019 at 10:38:19AM -0700, PGNet Dev wrote: > >> I suspect I've misunderstood usage of TLSv1.3 @ >> >> https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ >> >> Checking cipherlist for just TLSv1.3 ciphers FAILs here, >> >> openssl ciphers -stdname -s -V >> 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' >> Error in cipher list > > This is expected. Try: > > openssl ciphers -tls1_3 -stdname -s -V -ciphersuites > 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' > That works here, openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD Can you clarify WHY that's expected? Atm, it's inclear why it's working for Michael Wojcik ... different version? something's changed? And, in webserver ssl_cipher configs, specifying ONLY the tls13 ciphersuites fires a config error. Until I add a group, e.g. ECDHE, as well, to the spec. If this^^ is 'expected', is that, then, actually an error?
Re: cipherlist with only tlsv1.3 ciphers reports error?
>>> Configuration file difference? > >> which config file are you referring to? > > The default OpenSSL configuration file. openssl.cnf, in the directory > displayed by "openssl version -d". But I can't think offhand of anything in > the configuration file that I'd expect to have this sort of effect. I don't > think even engines would normally have any effect on cipher-list processing > this way. fyi, here /usr/bin/openssl version -v OpenSSL 1.1.0i-fips 14 Aug 2018 /usr/bin/openssl version -d OPENSSLDIR: "/etc/ssl" find /etc/ssl -type f | grep cnf /etc/ssl/openssl.cnf /usr/local/ssl-test/bin/openssl version -v OpenSSL 1.1.1c 28 May 2019 /usr/local/ssl-test/bin/openssl version -d OPENSSLDIR: "/usr/local/ssl-test" find /usr/local/ssl-test -type f | grep cnf (empty)
Re: cipherlist with only tlsv1.3 ciphers reports error?
> Works for me: > $ openssl ciphers -stdname -s -V > 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' simplifying to build defaults ./config -v \ --prefix=/usr/local/ssl-test \ --openssldir=/usr/local/ssl-test \ --libdir=lib64 \ -Wl,-rpath=/usr/local/ssl-test/lib64 make depend make builds with no apparent errors. tests pass make test ... All tests successful. Files=155, Tests=1410, 187 wallclock secs ( 7.50 usr 1.48 sys + 159.26 cusr 37.30 csys = 205.54 CPU) Result: PASS make[1]: Leaving directory '/usr/local/src/openssl11/openssl-1.1.1c' and after install make install_sw reports /usr/local/ssl-test/bin/openssl version OpenSSL 1.1.1c 28 May 2019 /usr/local/ssl-test/bin/openssl version -f -p platform: linux-x86_64 compiler: /usr/bin/gcc-9 -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -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 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG ldd /usr/local/ssl-test/bin/openssl linux-vdso.so.1 (0x7ffe91be9000) libssl.so.1.1 => /usr/local/ssl-test/lib64/libssl.so.1.1 (0x7f5e52c96000) libcrypto.so.1.1 => /usr/local/ssl-test/lib64/libcrypto.so.1.1 (0x7f5e527b) libdl.so.2 => /lib64/libdl.so.2 (0x7f5e525ac000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f5e5238e000) libc.so.6 => /lib64/libc.so.6 (0x7f5e51fd4000) /lib64/ld-linux-x86-64.so.2 (0x7f5e531df000) still fails as above, /usr/local/ssl-test/bin/openssl ciphers -v 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 139704422536256:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2549: /usr/local/ssl-test/bin/openssl ciphers -v ECDHE-ECDSA-AES256-GCM-SHA384 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD also, checking the DISTRO-build, /usr/bin/openssl version OpenSSL 1.1.0i-fips 14 Aug 2018 fails too, /usr/bin/openssl ciphers -v 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 140437655795520:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2193:
Re: cipherlist with only tlsv1.3 ciphers reports error?
> Works for me: heh. of COURSE it does! sanity check here, openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 140042399306176:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2549: > Different OpenSSL release? yes openssl version OpenSSL 1.1.1c 28 May 2019 > Difference in build configuration? yes openssl version -f -p platform: linux-x86_64 compiler: /usr/bin/gcc-9 -fPIC -pthread -m64 -Wa,--noexecstack -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -fno-common -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 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEATS -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -D_FORTIFY_SOURCE=2 which is quite different than yours. the config which I start with ./config -v \ --prefix=/usr/local/openssl11 \ --openssldir=/usr/local/openssl11 \ --libdir=lib64 \ -D_GNU_SOURCE \ -DOPENSSL_NO_BUF_FREELISTS \ -DOPENSSL_NO_HEARTBEATS \ -DPURIFY \ -DSSL_FORBID_ENULL \ -DTERMIO \ -Wa,--noexecstack \ -Wl,-z,relro,-z,now \ -Wall \ -Wl,-rpath=/usr/local/openssl11 \ -fno-common \ threads shared \ no-comp no-zlib no-zlib-dynaemic \ enable-ec_nistp_64_gcc_128 \ no-sctp \ no-idea \ no-mdc2 \ no-rc2 \ no-rc5 \ no-ssl3 \ no-weak-ssl-ciphers \ no-nextprotoneg That, too, is 'old' (been in use for a lng time ...), and probably can benefit from some clean-up. As to what of that^ is causing my fail ... ? not immediately clear what the culprit is. Before I start decomposing the config difference, anything obvious leap out at you? > Configuration file difference? which config file are you referring to?
cipherlist with only tlsv1.3 ciphers reports error?
I suspect I've misunderstood usage of TLSv1.3 @ https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ Checking cipherlist for just TLSv1.3 ciphers FAILs here, openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list but works if I add, e.g., 'ECDHE' group to the list openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE' 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD 0x13,0x01 - TLS_AES_128_GCM_SHA256 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ... Why doesn't the 1st attempt, without the group added, work?
Re: Error building app on RHEL 7 with openssl 1.1.1
On 7/18/19 3:37 PM, Mark Richter wrote:> I use: > > ./config --prefix=/opt/openssl1.1 --openssldir=/opt/openssl1.1 --libdir=lib no-shared zlib-dynamic just fyi, the options were simply referring to the linking issue, not an inclusive list; hence the ellipsis > I'm pretty sure I can't just use the defaults you provide because the app also includes libcurl, among others, which itself uses the "normal" OpenSSL on RHEL 7, which is 1.0.2 and not compatible with 1.1.1. sounds like your distribution needs drive your build choices. fwiw, I build local curl, as well as those 'others', with openssl 1.1.1c, in order to similarly deal with dependencies. the goal is a consistent openssl1.1.1c-using stack. I haven't found depending on the distros for that to be a winning proposition. i understand it's a deep, dark, rabbit-hole; YMMV. > My app needs to use 1.1.1 without interfering with other (shared) libraries it uses that were built with 1.0.2. It also needs to have 1.1.1 statically linked because we want to ship to customers that don't have 1.1.1 installed. I suppose we could include 1.1.1 in its own directory as part of our rpm, but I'd rather not. > > These errors appeared when I tried to link with the static 1.1.1 libraries. understood. here, I build nothing statically, and build & include all the pieces-n-parts of the 1.1.1c-consistent stack for any given app in a local repo. as above, you can soon start feeling like you're building your own distro. which we do, as well ... usually necessarily, but grudgingly.
Re: Error building app on RHEL 7 with openssl 1.1.1
On 7/18/19 1:34 PM, Mark Richter wrote: 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: haven't backtracked through the entire thread, but some of the errors were familiar, and noticed your comment re: "modified the Makefile" ... Are you (already) using 'config', & including the options: ./config \ --prefix=/usr/local/openssl \ --openssldir=/usr/local/openssl \ --libdir=lib64 \ -Wl,-rpath=/usr/local/openssl/lib64 \ ... Here, that configure & builds nicely without having to directly mod Makefile.
webserver+openssl 1.1.1c failing to use CHACHA20 ciphers, and fails to launch at all if just TLSv1.3 cipherlist is specified?
I run nginx 1.17.1 + openssl 1.1.1c on linux.
I typically configure recommended defaults for SSL usage, and it "just works",
with ssllabs reporting my sites as healthy with an "A+", fwiw.
Now, I'm currently working setting up a local-only server, attempting to get it
to use TLSv1.3/CHACHA20 only.
So I'm trying to tighten down restrictions in config. With my attempted
restrictions in place, I've found that I'm apparently NOT using
TLSv1.3/CHACHA20.
The current test setup follows; I'm not clear where the problem is -- in nginx,
openssl, or my config of either/both. I'm _guessing_ it's my usage/config ...
I've installed
which openssl
/usr/local/openssl/bin/openssl
openssl version
OpenSSL 1.1.1c 28 May 2019
nginx is built with/linked to this version
nginx -v
nginx version: nginx/1.17.1
ldd `which nginx` | grep ssl
libssl.so.1.1 => /usr/local/openssl/lib64/libssl.so.1.1
(0x7f95bdc09000)
libcrypto.so.1.1 => /usr/local/openssl/lib64/libcrypto.so.1.1
(0x7f95bd6f9000)
With this nginx config
server {
listen 10.0.1.20:443 ssl http2;
server_name test.dev.lan;
root /data/webapps/nulldir;
index index.html;
rewrite_log on;
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log info;
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-256-GCM-SHA384 TLS13-AES-128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305";
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_prefer_server_ciphers on;
ssl_trusted_certificate
"/usr/local/etc/ssl/myCA/myCA.chain.crt.pem";
ssl_certificate
"/usr/local/etc/ssl/test/test.ec.crt.pem";
ssl_certificate_key
"/usr/local/etc/ssl/test/test.ec.key.pem";
location / {
}
}
config check is ok,
nginxconfcheck
nginx: the configuration file /usr/local/etc/nginx/nginx.conf
syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test
is successful
and I see a TLS 1.3 handshake,
openssl s_client -connect 10.0.1.20:443 -CAfile
/usr/local/etc/ssl/myCA/myCA.chain.crt.pem
CONNECTED(0003)
Can't use SSL_get_servername
depth=2 O = dev.lan, OU = myCA, L = NewYork, ST = NY, C = US,
emailAddress = ad...@dev.lan, CN = myCA_ROOT
verify return:1
depth=1 C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT,
emailAddress = ad...@dev.lan
verify return:1
depth=0 C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA,
CN = test.dev.lan, emailAddress = ad...@dev.lan
verify return:1
---
Certificate chain
0 s:C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA, CN =
test.dev.lan, emailAddress = ad...@dev.lan
i:C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT,
emailAddress = ad...@dev.lan
---
Server certificate
-BEGIN CERTIFICATE-
MIIEhjCCBAygAwIBAgICELAwCgYIKoZIzj0EAwIwgbAxCzAJBgNVBAYTAlVTMQsw
...
VHldKgTNpiGuFA==
-END CERTIFICATE-
subject=C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA,
CN = test.dev.lan, emailAddress = ad...@dev.lan
issuer=C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT,
emailAddress = ad...@dev.lan
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1565 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
CA79B0596A2CCF19BBA9A49E086F99E7F811FAC8349888E37531E46B17FE35A9
Session-ID-ctx:
Resumption PSK:
9966170E5086490D231260B15CDA6852D0CCDED661D1C075BF0DE3334C89472B158F2524282DD5F1175381B4317D8DC9
PSK identity: None
PSK identity hint: None
Re: [openssl-users] TLS 1.3 and the release
I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu bionic. Yes, there is a package, but all the other packages depend upon 1.0.x and many things are linking against 1.0.x rather than 1.1, when both are installed... I don't know why they build stuff against 1.0.x rather than 1.1.0: I think it's a packaging oops. In the "I'm guessing this is NOT news to anyone HERE" category Even the packages that DO 'build against' 1.1.0 frequently do so by banking on deprecated symbols made possible by lazy (imo) api-compat usage. Packagers are frequently NOT cleaning up their openssl version-check logic, and cleaning out old-/deprecated- symbols. In my experience, most seem not to be interested, either; instead, the response mantra to entreaties about clean/modern "--api=1.1.0" compatibility is "that's not what the distros provide; just use that". -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?
On 6/4/17 4:51 PM, Jeffrey Walton wrote:
but the process STARTS with an apparently non-fatal error ...
Using configuration from /home/sec/newCA/openssl.cnf
Can't open root/database.attr for reading, No such file or directory
140013244086016:error:02001002:system
library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
file:crypto/bio/bss_file.c:81:
This usually indicates the OpenSSL conf file cannot be found. Its odd
that "Using configuration from /home/sec/newCA/openssl.cnf" is
reported.
Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
to isolate the issue (or maybe rule out its not a conf file problem).
The message above doesn't indicate that openssl.cnf can't be found. In
fact it explcitly states that it IS found and IS using it
>> Using configuration from /home/sec/newCA/openssl.cnf
It's the same openssl.cnf used in all the PRIOR steps, with not problem
whatsoever.
Rather it's
>> Can't open root/database.attr for reading, No such file or
directory
that's not found.
I've found that if I simply
touch root/database.attr
touch intermediate/database.attr
as already's been done with
touch root/database
touch intermediate/database
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?
I've a new, local CA for (primary) local, self-signed, elliptical cert issuance
& use.
I've built/installed,
openssl version
OpenSSL 1.1.0f 25 May 2017
I've created a ROOT crt & key, & and an INTERMEDIATE key & csr.
On exec of signing the INTERMEDIATE key with the ROOT.
openssl ca -batch \
-notext \
-extensions ext_intermediate \
-config /home/sec/newCA/openssl.cnf \
-name ca_root \
-in intermediate/csr/newCA.INTERMEDIATE.csr.pem \
-out intermediate/certs/newCA.INTERMEDIATE.crt.pem
It appears to complete -- the cert's created
openssl x509 \
-noout \
-text \
-in intermediate/certs/newCA.INTERMEDIATE.crt.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4096 (0x1000)
Signature Algorithm: ecdsa-with-SHA256
...
but the process STARTS with an apparently non-fatal error ...
Using configuration from /home/sec/newCA/openssl.cnf
Can't open root/database.attr for reading, No such file or directory
140013244086016:error:02001002:system
library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
file:crypto/bio/bss_file.c:81:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 4096 (0x1000)
Validity
Not Before: Jun 4 18:54:29 2017 GMT
Not After : Jun 2 18:54:29 2027 GMT
...
Write out database with 1 new entries
Data Base Updated
The only mention of
root/database
is in my openssl.conf
...
[ ca_root ]
dir = root
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/database <-
unique_subject= yes
...
PRIOR to creating the ROOT key, I
touch root/database
touch intermediate/database
AFTER the signing,
ls -al root/database*
-rw-r--r-- 1 root root 167 Jun 4 11:54 root/database
-rw-r--r-- 1 root root 21 Jun 4 11:54 root/database.attr
-rw-r--r-- 1 root root 0 Jun 4 11:51 root/database.old
and if I RE-exec the cmd,
openssl ca -batch \
...
there's no more error
Using configuration /home/sec/newCA/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
...
Checking
cat root/database.attr
unique_subject = yes
Which appears (?) to originate from the "[ ca_root ]" in my openssl.cnf
Do I need to touch, or manually populate, the
root/database.attr
prior to first exec to init as well?
Or is this a bug?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL and RPATH's
On 5/31/17 3:16 AM, Wouter Verhelst wrote:
> On 30-05-17 18:12, PGNet Dev wrote:
> [...]
>> with lots of apps still not at all v110
>> compatible, or at best broken in their attempts, having local builds of
>> both v110x and v102x is extremely useful -- and RPATH'ing makes that
>> trivially manageable.
>
> That's exactly my point -- you don't need to use RPATH to handle that
> (very common) case. You just need to link against the correct .so file
> at compile time (which can be handled by installing them in separate
> directories and using -L to specify which one to link to); the runtime
> dynamic linker will then find a v1.1 version of OpenSSL for applications
> compiled against 1.1.0x, or a v1.0.2 version for applications compiled
> against 1.0.2x. It's that simple.
>
> RPATH is useful if the SONAME is the same but the libraries aren't, for
> whatever reason (e.g., local patches). Other than that, you don't need
> it,
Not quite.
System Install
ls -al /usr/lib64/lib{ssl,crypto}.*
lrwxrwxrwx 1 root root 25 Feb 16 16:54 /usr/lib64/libcrypto.so
-> /lib64/libcrypto.so.1.0.0*
lrwxrwxrwx 1 root root 22 Feb 16 16:54 /usr/lib64/libssl.so ->
/lib64/libssl.so.1.0.0*
ldd /usr/lib64/libssl.so | egrep "ssl|crypto"
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0
(0x7f390d0eb000)
Local Install
ls -al /usr/local/openssl10/lib64/lib{ssl,crypto}.*
-rw-r--r--+ 1 root root 4.7M May 30 08:38
/usr/local/openssl10/lib64/libcrypto.a
lrwxrwxrwx 1 root root 18 May 30 08:38
/usr/local/openssl10/lib64/libcrypto.so -> libcrypto.so.1.0.0*
-r-xr-xr-x+ 1 root root 2.9M May 30 08:38
/usr/local/openssl10/lib64/libcrypto.so.1.0.0*
-rw-r--r--+ 1 root root 737K May 30 08:38
/usr/local/openssl10/lib64/libssl.a
lrwxrwxrwx 1 root root 15 May 30 08:38
/usr/local/openssl10/lib64/libssl.so -> libssl.so.1.0.0*
-r-xr-xr-x+ 1 root root 503K May 30 08:38
/usr/local/openssl10/lib64/libssl.so.1.0.0*
ldd /usr/local/openssl10/lib64/libssl.so | egrep "ssl|crypto"
libcrypto.so.1.0.0 =>
/usr/local/openssl10/lib64/libcrypto.so.1.0.0 (0x7f3bcd526000)
Local Install
ls -al /usr/local/openssl11/lib64/lib{ssl,crypto}.*
-rw-r--r--+ 1 root root 4.9M May 30 08:50
/usr/local/openssl11/lib64/libcrypto.a
lrwxrwxrwx 1 root root 16 May 30 08:50
/usr/local/openssl11/lib64/libcrypto.so -> libcrypto.so.1.1*
-rwxr-xr-x+ 1 root root 3.0M May 30 08:50
/usr/local/openssl11/lib64/libcrypto.so.1.1*
-rw-r--r--+ 1 root root 745K May 30 08:50
/usr/local/openssl11/lib64/libssl.a
lrwxrwxrwx 1 root root 13 May 30 08:50
/usr/local/openssl11/lib64/libssl.so -> libssl.so.1.1*
-rwxr-xr-x+ 1 root root 509K May 30 08:50
/usr/local/openssl11/lib64/libssl.so.1.1*
ldd /usr/local/openssl11/lib64/libssl.so | egrep "ssl|crypto"
libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1
(0x7f4be3d5d000)
etc ...
> and it's generally a bad idea.
And, IMO, that's just bad advice. RPATH is perfectly fine, and this^ is
exactly what it exists for. Feel free to use it or not, but don't FUD
perfectly legitimate functionality as a 'bad idea'.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag?
On 5/30/17 9:01 AM, Jakob Bohm wrote: Actually, in my testing of earlier 1.0.x releases, sha256 etc. are only missing from the help message, they are actually there, also as commands. On 5/30/17 9:14 AM, Salz, Rich wrote: >> Then I've misunderstood the presence of the "-DSHA256_ASM" flag. >> >> What's it specifically used for? > > To remind me to double-check my answers? :( > > Sorry, they are present. The difference is that the help message in 1.0.2 isn't complete. Did you try the commands directly? Well, touch /tmp/test.txt /usr/local/openssl10/bin/openssl dgst -sha256 /tmp/test.txt SHA256(/tmp/test.txt)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /usr/local/openssl11/bin/openssl dgst -sha256 /tmp/test.txt SHA256(/tmp/test.txt)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 NOW I have! See? THAT'S what you get when you waste time RTFM-ing! ;-) Thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL and RPATH's
The only reason why you would ever want to use RPATH with OpenSSL is because you need to install a particular old version of libssl (or libcrypto) that has the same SONAME as the system-default, but where you don't want to use that system-default one -- but why would you want to do that? Security updates are a good thing, usually. On 5/30/17 8:58 AM, Jakob Bohm wrote: > On 29/05/2017 16:39, Wouter Verhelst wrote: >> ... >> The only reason why you would ever want to use RPATH with OpenSSL is ... Well, 'different strokes' to be sure ... but, here, especially with lots of apps still not at all v110 compatible, or at best broken in their attempts, having local builds of both v110x and v102x is extremely useful -- and RPATH'ing makes that trivially manageable. My $.02. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag?
On 5/30/17 8:25 AM, Salz, Rich wrote:
The results are both functional, but the v102l build is missing
sha{224|256|384|512} digests
Right; those digests are not in 1.0.2
Then I've misunderstood the presence of the "-DSHA256_ASM" flag.
What's it specifically used for?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag?
I'm building separate local instances of latest Openssl v1.1.0 & v1.0.2 on
linux64, to keep not-yet-v110-compliant apps happy.
The results are both functional, but the v102l build is missing
sha{224|256|384|512} digests
v 1.0.2l
/usr/local/openssl10/bin/openssl version
OpenSSL 1.0.2l 26 Jan 2017
/usr/local/openssl10/bin/openssl version -f
compiler: /usr/bin/gcc-7 -I. -I.. -I../include -fPIC
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY
-DSSL_FORBID_ENULL -DTERMIO -Wa,--noexecstack -Wall -fno-common
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
/usr/local/openssl10/bin/openssl help
...
Message Digest commands (see the `dgst' command for more
details)
md4 md5 rmd160sha
sha1
...
ldd /usr/local/openssl10/bin/openssl | egrep 'lib(ssl|crypto)'
libssl.so.1.0.0 => /usr/local/openssl10/lib64/libssl.so.1.0.0
(0x7f1619534000)
libcrypto.so.1.0.0 =>
/usr/local/openssl10/lib64/libcrypto.so.1.0.0 (0x7f16190aa000)
v 1.1.0f
/usr/local/openssl11/bin/openssl version
OpenSSL 1.1.0f 25 May 2017
/usr/local/openssl11/bin/openssl version -f
/usr/local/openssl11/bin/openssl version -f
compiler: /usr/bin/gcc-7 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
-DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM
-DOPENSSL_API_COMPAT=0x1010L -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS
-DOPENSSL_NO_HEARTBEAT -DPURIFY -DSSL_FORBID_ENULL -DTERMIO
-DOPENSSLDIR="\"/usr/local/openssl11\""
-DENGINESDIR="\"/usr/local/openssl11/lib64/engines-1.1\"" -Wa,--noexecstack
-Wall -fno-common -Wa,--noexecstack
/usr/local/openssl11/bin/openssl help
...
Message Digest commands (see the `dgst' command for more
details)
blake2b512blake2s256gost md4
md5 rmd160sha1 sha224
sha256sha384sha512
...
ldd /usr/local/openssl11/bin/openssl | egrep 'lib(ssl|crypto)'
libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1
(0x7fc9c70f4000)
libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1
(0x7fc9c6c48000)
The "-DSHA256_ASM" flag is present for the 102l build. Is there an additional,
specific flag required to enable the higher bit-depth digests for v102l that
I've missed.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] [SOLVED?] Re: openssl 1.0.2h pkcs12 export fails @ "digital envelope routines:EVP_PBE_CipherInit:unknown cipher"
Reading @ https://www.openssl.org/docs/manmaster/apps/pkcs12.html "By default the private key is encrypted using triple DES and the certificate using 40 bit RC2." which clearly implies, with RC2 disabled (it is), that'll cause a problem in default config. Adding the options openssl pkcs12 -export \ -descert fixes the problem, insofar as no error's caused on export. Would code to enable/use "-descert" as default cert, in the case of RC2 disabled, be called for? Or, perhaps with RC2 considered 'weak' these days, worhtwhile to make "-descert" the default? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.0.2h pkcs12 export fails @ "digital envelope routines:EVP_PBE_CipherInit:unknown cipher"
I'm setting up a new, local CA. The local openssl instance is openssl version OpenSSL 1.0.2h 3 May 2016 config'd/built with ... no-comp no-zlib no-zlib-dynamic \ enable-ec_nistp_64_gcc_128 \ enable-rfc3779 \ enable-ecdsa \ no-idea \ no-mdc2 \ no-rc2 \ no-rc5 \ no-ssl2 \ no-ssl3 \ no-weak-ssl-ciphers pkcs12 export, which worked a (long) while ago, now fails, openssl genrsa -des3 -aes256 -out test_CA.key 4096 openssl req -new -x509 -sha512 -days 365 -set_serial 01 -config ./openssl.cnf -subj "/C=US/ST=ST/L=CITY/O=example.com/OU=test_CA/emailAddress=s...@example.com/CN=test_CA" \ -key test_CA.key \ -out test_CA.crt openssl pkcs12 -export \ -intest_CA.crt \ -inkey test_CA.key \ -out test_CA.p12 140199860266640:error:060740A0:digital envelope routines:EVP_PBE_CipherInit:unknown cipher:evp_pbe.c:181: 140199860266640:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:p12_decr.c:87: 140199860266640:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:188: 140199860266640:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt error:p12_add.c:213: Looks like the config above removed a required cipher? Perhaps too stringent ... What's the fix/workaround to get pkcs12 export working again? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
On 04/04/2016 07:08 PM, Jakob Bohm wrote: On 05/04/2016 02:57, PGNet Dev wrote: Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. http://bfy.tw/565B Troll! I didn't ask what things in the entire world were historically named "SPAM-L" (first two Google results are messages that a list by that name was shut down in 2009, third is a page announcing a new generic mailing list unrelated to discussing things with the OpenSSL list administrators). I was asking where Victor wanted the discussion to be moved, since he gave a vague answer "SPAM-L" (which could refer to almost any spam discussion list) and didn't provide an address where those in the thread could ask him directly. And using an URL shortener to point to another URL shortener (which actually hides the final Google page with a non-removable popup) is spammy behavior. Wow, you're special. Do not email me directly/offlist again. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. http://bfy.tw/565B -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
Is there nowhere else this interminable thread can be taken? Some of us actually subscribe to this list to actually follow *openssl* use & issues. Take it up with the list admins directly? On 04/04/2016 05:39 PM, Jakob Bohm wrote: On 05/04/2016 01:47, Johann v. Preußen wrote: '/No one (until about 2 hours ago) were discussing how the // //particular "From" address got past the "you must be // //subscribed to post" filter/' actually, i first posted on this issue c. 76 hours ago. Not in this thread on openssl-users as far as I can tell. '/maybe the spoofed From address happened to be a subscriber/' is it possible that openssl still does not know if the email addr is a real subscriber? I have no way of knowing since I am not one of the list admins. '/maybe there is a bug in the list management software or configuration/' yes, i surely hope someone is looking into this possibility. further, not only was owenevans98 able to post an original message (the subject of this thread), but there was a subsequent posting in reply to another thread. thus, the conclusion that owenevans98 was not only able to post but was|is receiving the listserv mailings is self-evident. the fact that this two-way comm path came into existence means that the listserv database was corrupted and that the original posting was not some slip-up in permitting an un-authorized one-time posting. Which other thread was that? jakob, i appreciate your taking of the time to detail some of openssl's listserv practices and view-points. perhaps it is best to set forth the synopses of my views: I am not a list admin or other official team member, I am just an active list member who wants to avoid the list admins following bad advice from people like you and Ben Humpert. 1. make certain ' owenevans98' and any other illegitimate posters are not receiving listserv mailings; Question is if owenevans97 is an illegitimate poster or a legitimate poster whose e-mail address was spoofed. Anyway, the OpenSSL mailings are all being indexed on the world wide web by multiple organizations, where anyone can read them. 2. stop publishing the subscriber's protected PII in the clear; and Again, I see no sign this is happening other than the age-old inclusion of original from and reply addresses in postings (which is limited to those who post, and doesn't affect those who only subscribe). 3. control postings of anchors. I disagree. A number of e-mail clients (MUAs) automatically turn textual URLs into anchors and make it very difficult (if not impossible) for the posting user to avoid this. And people professional enough to understand most of the stuff on OpenSSL mailing list also know not to click on links in strange e-mails and forum posts. according to your comment quoted, supra, it seems that the step indicated in Item 1 has yet to be taken. I wouldn't know. Item 2 can be implemented by inaugurating a subscriber-managed profile and merely publishing a user handle linked thereto. thus, you can shift the onus to the subscriber to reveal whatever info they wish rather than arbitrarily exposing to the world a subscriber's personal name, email addr, and work-force association. Did you read and understand any of that which I wrote, or are you just trolling? in the case of Item 3, i understand all of the reasons for having links (not html anchors) in postings. it is a very minor inconvenience for someone who has a burning interest in viewing a link to copy the clear-text link into a browser versus clicking on an anchor description which could lead the subscriber far astray from what the description says. it also enhances the subscriber experience to visually see where the link is going instead of having the actual target obscured by a description that may be deceptive, merely misleading, or non-apparent (i.e., 'click here'). jakob, you also mention concern re MTA operators having some issues with changes you may make to the listserv ops. please note: none of the three (3) items, supra, i have suggested have any impact on other MTA operators as they are totally internal-control enhancement proc's. I am an MTA operator, I am not a listserv op. I was posting concerns I have as an MTA operator and list member with stupid changes suggested by you and Ben Humpert. i cannot understand why openssl's filtering missed the fact that the posting that is subject of this thread predominated in symbols and control characters, contained no actual message text, and still went through. hopefully, someone is also looking into why this happened. Did you read the brief but very clear message posted on 2016-04-02 15:24 UTC by Rich Salz (who is an OpenSSL team member and may have access to the listserv configuration details not published to avoid helping spammers)? P.S. Please don't CC list members on replies to the list, it causes duplicate copies to reach them (since list membership is required to post to the list
Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
On 03/16/2016 02:52 PM, Jeffrey Walton wrote: If I can ask as a user, if I say do this _all the time_, then would it be easiest on you? make depend && make clean && make Or is there something else you would recommend? If it were up to _me_, I'd move to a cmake build system, with clear & completely documented params in config files. Since that's not likely going to happen any time soon, if at all, to answer your question ... TBH, I don't really mind one way or the other. Any working build process is frankly fine with me ... as long as it's consistently & thoroughly documented, and, if followed, doesn't generate K's of warnings/errors. As far as not configuring because stddef.h, that sounds like a bug. Which sounds like it will/should go away in 1.1.0, as the use of 'make depend' is going away? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
On 03/14/2016 08:58 AM, PGNet Dev wrote: On 03/14/2016 08:26 AM, PGNet Dev wrote: Which I currently attempt to do, but get the reported errors about not finding the stddef.h include etc. Here, https://rt.openssl.org/Ticket/Display.html?id=4169=guest=guest it simply says "fixed in 1.1" There's no indication what the fix is -- use make depend, or don't use it? And, no idea how we're _supposed_ to get to a successful/reliable build in 1.0.2x series. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
On 03/14/2016 08:26 AM, PGNet Dev wrote: Which I currently attempt to do, but get the reported errors about not finding the stddef.h include etc. Specifically, cd test rm -rf * wget https://www.openssl.org/source/openssl-1.0.2g.tar.gz tar zxvf openssl-1.0.2g.tar.gz cd openssl-1.0.2g ./config --openssldir=/home/work/sslTEST --libdir=lib64 \ threads shared -D_GNU_SOURCE -DPURIFY -DTERMIO -fno-common -Wl,-rpath=/home/work/sslTEST/lib64 -Wa,--noexecstack -Wl,-z,relro,-z,now -Wall ... Configured for linux-x86_64. *** Because of configuration changes, you MUST do the following before *** building: make depend make depend making depend in crypto... make[1]: Entering directory '/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto' makedepend: warning: cryptlib.c (reading /usr/include/stdlib.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: cryptlib.c (reading /usr/include/sys/types.h, line 146): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/alloca.h, line 24): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/string.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/unistd.h, line 226): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/stdio.h, line 33): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/_G_config.h, line 15): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/wchar.h, line 51): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/libio.h, line 49): cannot find include file "stdarg.h" not in ./stdarg.h not in ../stdarg.h not in ../include/stdarg.h not in /usr/include/stdarg.h makedepend: warning: cryptlib.c (reading ../include/openssl/buffer.h, line 68): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading ../include/openssl/bio.h, line 67): cannot find include file "stdarg.h" not in ./stdarg.h not in ../stdarg.h not in ../include/stdarg.h not in /usr/include/stdarg.h makedepend: warning: o_str.c (reading o_str.h, line 63): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: o_str.c (reading /usr/include/strings.h, line 28): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: o_dir.c (reading
Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
On 03/14/2016 08:24 AM, lists wrote: Did you mean "./config ..."? yep. Must use it, (1) https://wiki.openssl.org/index.php/Compilation_and_Installation Dependencies If you are prompted to run make depend, then you must do so. Which I currently attempt to do, but get the reported errors about not finding the stddef.h include etc. I cannot see exactly what is that you find confusing. That the wiki says you don't need to, "Compilation After configuring the library, you should run make. If prompted, there's usually no need to make depend since you are building from a clean download." ^^ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or 'no-comp no-bio' configure options?
My read of "no-comp Disables compression independent of zlib. OPENSSL_NO_COMP will be defined in the OpenSSL headers." is that this disables compression methods OTHER than zlib. Is the intent, instead, that it disables ALL compression, REGARDLESS of the presence/setting of zlib? This was helpful "When do I need zlib in OpenSSL?" http://stackoverflow.com/questions/23772816/when-do-i-need-zlib-in-openssl 'no-comp' disables ALL compression, including any zlib comp; seems that's the recommendation there. I ended up with ./config ... no-comp no-zlib no-zlib-dynamic ... leaving out 'no-bio' until at least v1.1.0 release. No errors/warnings on the build. Other than the 'make depend' noise; that's another thread. Thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2g build linking to wrong libs -- 'system' instead of 'own'. How to correct?
On 03/10/2016 11:07 AM, Jeffrey Walton wrote: What's the correct config+build procedure for ending up with self-consistent linking? https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs Didn't realize that I'd need to rpath a package within its own build. Appears libssl & libcrypto are functionally separate builds, and the rpath's needed. Not sure why you wouldn't want the rpath as default, so as to link using the libs you "just built". In any case, works as advertised. Thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or 'no-comp no-bio' configure options?
On 03/10/2016 10:19 AM, PGNetwork Dev wrote: ./config no-comp ... subsequent 'make' fails make ... enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib' Adding one or both of no-zlib no-zlib-dynamic should handle that. My read of "no-comp Disables compression independent of zlib. OPENSSL_NO_COMP will be defined in the OpenSSL headers." is that this disables compression methods OTHER than zlib. Is the intent, instead, that it disables ALL compression, REGARDLESS of the presence/setting of zlib? I've not built with no-bio, suspect it is much more intimately entangled and may not be practical in 1.0.2g; there's been a lot of work done in master to clean up various optional exclusions, I think no-bio is expected to be working there. Ah, I see the diffs in the 1.0.2 -> 1.1.0 changelog at https://www.openssl.org/news/changelog.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.0.2g build linking to wrong libs -- 'system' instead of 'own'. How to correct?
I'm building 1.0.2g on linux64. I'm trying to get a self-consistent build, linked to the right libs. Building cd ./openssl-1.0.2g ./config \ --openssldir=/home/dev/ssl --libdir=lib64 \ threads shared zlib -D_GNU_SOURCE -DPURIFY -DTERMIO \ -Wa,--noexecstack -Wl,-z,relro,-z,now -Wall -fno-common make depend make make install Then checking ldd /home/dev/ssl/lib64/*.so* | egrep "ssl|crypto" /home/dev/ssl/lib64/libcrypto.so: /home/dev/ssl/lib64/libcrypto.so.1.0.0: /home/dev/ssl/lib64/libssl.so: libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x7f6154f37000) /home/dev/ssl/lib64/libssl.so.1.0.0: libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x7fd60fbbc000) Why are these libs linked to SYSTEM libs, not the just-built libs, in the specified $openssldir/$libdir ? It can be fixed after the fact, patchelf --set-rpath "/home/dev/ssl/lib64" --force-rpath /home/dev/ssl/lib64/libssl.so.1.0.0 ldd /home/dev/ssl/lib64/libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /home/dev/ssl/lib64/libcrypto.so.1.0.0 (0x7ff7f06fa000) but that shouldn't be required. What's the correct config+build procedure for ending up with self-consistent linking? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.0.2g build fails with 'no-comp' or 'no-comp no-bio' configure options?
I'm building openssl 1.0.2g on linux64
With my usual
./config ...
I end up with a successful build/install
openssl version
OpenSSL 1.0.2g 1 Mar 2016
If I add
./config no-comp ...
subsequent 'make' fails
make
...
make[1]: Leaving directory
'/usr/local/src/openssl/openssl-1.0.2g/ssl'
making all in apps...
make[1]: Entering directory
'/usr/local/src/openssl/openssl-1.0.2g/apps'
rm -f openssl
shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ];
then \
shlib_target="linux-shared"; \
elif [ -n "" ]; then \
FIPSLD_CC="/usr/bin/gcc-5"; CC=/usr/local/ssl/fips-2.0/bin/fipsld;
export CC FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
rand.o engine.o ocsp.o prime.o ts.o srp.o" \
LIBDEPS=" $LIBRARIES -Wl,-z,relro,-z,now -ldl -lz" \
link_app.${shlib_target}
make[2]: Entering directory
'/usr/local/src/openssl/openssl-1.0.2g/apps'
enc.o: In function `enc_main':
enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib'
collect2: error: ld returned 1 exit status
../Makefile.shared:171: recipe for target 'link_app.gnu' failed
make[2]: *** [link_app.gnu] Error 1
make[2]: Leaving directory
'/usr/local/src/openssl/openssl-1.0.2g/apps'
Makefile:156: recipe for target 'openssl' failed
make[1]: *** [openssl] Error 2
make[1]: Leaving directory
'/usr/local/src/openssl/openssl-1.0.2g/apps'
Makefile:292: recipe for target 'build_apps' failed
make: *** [build_apps] Error 1
Adding further
./config no-comp no-bio ...
'make' fails again, differently
make
...
making all in crypto...
make[1]: Entering directory
'/usr/local/src/openssl/openssl-1.0.2g/crypto'
/usr/bin/gcc-5 -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE
-DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY
-DSSL_FORBID_ENULL -DTERMIO -Wa,--noexecstack -Wall -fno-common
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DCHAPOLY_x86_64_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -O3 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -fmessage-length=0
-grecord-gcc-switches -march=x86-64 -mtune=nocona -c -o cpt_err.o cpt_err.c
In file included from cpt_err.c:63:0:
../include/openssl/err.h:149:5: error: unknown type name
'CRYPTO_THREADID'
CRYPTO_THREADID tid;
^
../include/openssl/err.h:355:36: error: unknown type name
'CRYPTO_THREADID'
void ERR_remove_thread_state(const CRYPTO_THREADID *tid);
^
: recipe for target 'cpt_err.o' failed
make[1]: *** [cpt_err.o] Error 1
make[1]: Leaving directory
'/usr/local/src/openssl/openssl-1.0.2g/crypto'
Makefile:286: recipe for target 'build_crypto' failed
make: *** [build_crypto] Error 1
Are additional/different config options required to enable/support the
'no-comp' & 'no-bio' options?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
Actually, the actual admonition is more emphatic I'm prompted Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend " Configured for linux-x86_64. *** Because of configuration changes, you MUST do the following before *** building: make depend " -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 'makedepend' in openssl builds: clarify need and correct usage
I'm building openssl 1.0.2g on linux64. After ./configure ... I'm prompted Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Exec'ing the 'make depend' stage returns lots of warnings, make depend making depend in crypto... make[1]: Entering directory '/usr/local/src/openssl/openssl-1.0.2g/crypto' makedepend: warning: cryptlib.c (reading /usr/include/stdlib.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: cryptlib.c (reading /usr/include/sys/types.h, line 146): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/alloca.h, line 24): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h ... On the distro, stddef.h is available at /usr/include/linux/stddef.h /usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h /usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h Reading wiki & reports at openssl, there's confusing, if not conflicting, advice. Must use it, (1) https://wiki.openssl.org/index.php/Compilation_and_Installation Dependencies If you are prompted to run make depend, then you must do so. Its not just for developers who are updating sources. Its required to update the standard distribution once configuration options change. Don't need it (2) https://wiki.openssl.org/index.php/Compilation_and_Installation Compilation After configuring the library, you should run make. If prompted, there's usually no need to make depend since you are building from a clean download. (3) https://rt.openssl.org/Ticket/Display.html?id=3566=guest=guest "Obviously this needs fixing but as a workaround: if you're building from scratch (or after "make clean") it should compile fine with without doing "make depend". Steve. -- Dr Stephen N. Henson. OpenSSL project core developer." Re: 'makedepend', https://en.wikipedia.org/wiki/Makedepend makedepend was developed as part of MIT's Project Athena. It was used extensively in building X11 and ancillary packages, but has since become superseded by the dependency generation facilities of various compilers, and is now used primarily as a worst-case fallback, e.g. by depcomp and GNU Automake. Further, a quick check (https://www.google.com/search?q=makedepend+stddef ) shows that there's a long history (unresolved?) re: not finding the sys's stddef.h Digging around some more, I find that virtually the same issue was raised on openssl-dev in Apr 2015, https://mta.openssl.org/pipermail/openssl-dev/2015-April/001263.html [openssl-dev] `make depend`, advised by ./config, fails to find stddef.h in system/compiler path. old bug (#3566) says don't bother with `make depend`? true, or another bug? with no reply at all. What, then, IS the current need for 'makedepend' in openssl, and what, exactly, is the correct/recommended usage for its use in an openssl build? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
getting both OCSP Response Status: successful and an Response Verify Failure error ?
testing an ocsp query to a local openssl ocsp 'server', openssl ocsp \ -issuer /svr/demoCA/certs/CA/CA.cert.pem \ -cert /svr/demoCA/certs/domains/testdomain.cert.pem \ -url http://localhost: \ -resp_text i get what seems to be a successful response of good CertStatus, OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: DC = Auth, DC = testdomain, DC = loc, CN = OCSP Responder, O = MyCO, OU = http://testdomain.loc/Auth, L = myCity, ST = NY, C = US Produced At: Mar 24 00:53:07 2010 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 573...DAF Issuer Key Hash: E70...B7E Serial Number: 126...498 Cert Status: good This Update: Mar 24 00:53:07 2010 GMT Response Extensions: OCSP Nonce: 041...37A Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha512WithRSAEncryption Issuer: DC=Auth, DC=tesdomain, DC=loc, CN=MyCO CA, O=MyCO, OU=http:\/\/testdomain.loc\/Auth, L=myCity, ST=CA, C=US Validity Not Before: Mar 24 00:11:10 2010 GMT Not After : Mar 21 00:11:10 2020 GMT Subject: DC=Auth, DC=tesdomain, DC=loc, CN=OCSP Responder, O=MyCO, OU=http://testdomain.loc/Auth, L=myCity, ST=CA, C=US Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): 00:c4:d3:65:59:1d:04:be:d7:bb:5d:46:b2:d2:88: ... 88:bf:3f:11:68:db:08:f8:ba:ae:02:1f:07:14:78: 27:33:e9 Exponent: 65537 (0x10001) X509v3 extensions: Netscape Cert Type: SSL Client, SSL Server, S/MIME, Object Signing Netscape Comment: OpenSSL OCSP Responder Certificate X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: OCSP Signing X509v3 Basic Constraints: CA:FALSE X509v3 Subject Alternative Name: critical DNS:ocsp.testdomain.loc Signature Algorithm: sha512WithRSAEncryption 82:83:5f:86:1d:23:b4:e1:23:cb:04:e6:8e:f6:a1:e6:4a:3f: ... 3f:b2:23:8b:d9:b1:39:53 -BEGIN CERTIFICATE- MIIG6zCCBNOgAwIBAgIBATANBgkqhkiG9w0BAQ0FADCB9TEYMBYGCgmSJomT8ixk ... +6HEmqK1GCxcDsDUV+nlZ7Rcq4tZgk5b0fK4YiK25YRxtGM/f2hCP7Iji9mxOVM= -END CERTIFICATE- Response Verify Failure 32044:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:122:Verify error:unable to get local issuer certificate /svr/demoCA/certs/domains/testdomain.cert.pem: good This Update: Mar 24 00:53:07 2010 GMT But still get this complaint about local issuer certificate, which, iiuc, has to be available to get the query result back in the 1st place. Or does this error mean something else -- if so, what might that be? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: getting both OCSP Response Status: successful and an Response Verify Failure error ?
On Wed, Mar 24, 2010 at 4:46 AM, Dr. Stephen Henson st...@openssl.org wrote: The path of the responder certificate has to be validated so you need to pass the root CA using the -CAfile or -CApath command line arguments. adding -CAfile did the trick -- adding it to BOTH the server-launch cmd, AND the client-query. the server HAD been launched with -CA file already specified ... i note that, -CA file CA certificate -CAfile file trusted certificates file to understand -- why wouldn't passing -CA file be sufficient? wouldn't the CA certificate be trusted implicitly, without having to _also_ specify it with -CAfile? just a bit unclear ... thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
what are the minimal KeyUsage requirements for an OCSP-only, single-purpose cert?
I'm planning to run openssl ocsp in server mode, openssl ocsp \ -index /svr/demoCA/index.txt \ -port \ -CA /svr/demoCA/certs/CA/CA.cert.pem \ -rsigner /svr/demoCA/crl/OCSP.cert.pem \ -rkey /svr/demoCA/crl/OCSP.privkey.pem \ -text -out /var/log/ocsp.log where OCSP.cert.pem is a single-purpose cert, only for the OCSP responder. What's the MINIMAL (Extended)KeyUsage for the cert? Currently, I have cat /svr/demoCA/crl/OCSP.cert.pem | grep -i usage -A1 X509v3 Extended Key Usage: OCSPsigning -- X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment Obviously, the OCSPsigning Extended usage is required. Which, if any/all, of the Digital Signature, Non Repudiation, Key Encipherment KeyUsage specifications are required, if this cert will be used ONLY for/by the OCSP responder daemon? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: what are the minimal KeyUsage requirements for an OCSP-only, single-purpose cert?
hi, On Tue, Mar 23, 2010 at 4:56 PM, Dr. Stephen Henson st...@openssl.org wrote: Which, if any/all, of the Digital Signature, Non Repudiation, Key Encipherment KeyUsage specifications are required, if this cert will be used ONLY for/by the OCSP responder daemon? Well Key Encipherment is not required and there's the usual can of worms associated with the NR bit. I'd say just digital signature is sufficient. Thanks. Not sure what the usual can of worms refers to; worth a bit of digging, I suppose. Also, in an OCSP cert's 'type', nsCertType = server, client, objsign Is client really necessary? Server Objsign I can understand ... or, is it similar to SMTP where there exist both server client components? Cheers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: what are the minimal KeyUsage requirements for an OCSP-only, single-purpose cert?
On Tue, Mar 23, 2010 at 4:54 PM, Patrick Patterson ppatter...@carillonis.com wrote: where OCSP.cert.pem is a single-purpose cert, only for the OCSP responder. I hope you realize that there are MANY warnings against doing this for other than test purposes - for one thing, the server will fall over and die if it encounters any sort of error at all (there is an option that you can give it to stop it doing that that I can't recall at the moment, but I still wouldn't trust it for any sort of load at all). Alas, I realize no such thing :-( By doing this, what do you mean? Running an OCSP responder, or having a single-purpose cert? Can you please expound a bit? What's the MINIMAL (Extended)KeyUsage for the cert? Well, according to the framers of the FBCA Certificate Policy, and the CertiPath certificate policy (which count among them, several of the authors of the OCSP standards), KU for an OCSP server should be: digitalSignature, nonRepudiation with an EKU of: OCSPSigning and the OCSPNoCheck extension present (to avoid looping). Maybe I'm reading the wrong doc. @, http://www.idmanagement.gov/fpkipa/documents/CertCRLprofileForCP.pdf X.509 Certificate and Certificate Revocation List (CRL) Extensions Worksheet 10: Certificate Profile for Delegated OCSP Responders Pg 51 seems to imply only required KU of 'digitalSignature'. no? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: what are the minimal KeyUsage requirements for an OCSP-only, single-purpose cert?
On Tue, Mar 23, 2010 at 5:41 PM, Dr. Stephen Henson st...@openssl.org wrote: If you aren't sorry you did you might be the first person who isn't. Just warning you... noted. It's a deprecated extension from long ago. Best leave it out all together. didn't realize. do now, http://www.openssl.org/docs/apps/x509v3_config.html#DEPRECATED_EXTENSIONS Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
