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
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'.
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 c
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 /s
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
> 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
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
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
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
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
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
>>> 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
> 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 \
> 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
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'
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
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
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
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
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
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
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
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.
>>
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
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
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
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
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 \
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 "S
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
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
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
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 i
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
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
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
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
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
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 \
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
...
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
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,
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
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,
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
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
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
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,
48 matches
Mail list logo
