Hi,
Using OpenSSL 1.0.1j 15 Oct 2014 on a GNU/Linux machine, I observe that if
openssl s_server receives a ClientHello with FALLBACK_SCSV before the actual
ciphersuites, it breaks the handshake with a fatal handshake_failure(40) alert,
regardless of whether the version is the highest supported or
Hi,
Using OpenSSL 1.0.1h 5 Jun 2014, -Verify does not have the same meaning
depending on whether TLS or DTLS is used, when a PSK ciphersuite is selected.
More precisely, the following fails:
openssl s_server -nocert -psk abc123 -Verify 10 -dtls1
openssl s_client -psk abc123 -dtls1
with server
Hi,
Using OpenSSL 1.0.1h 5 Jun 2014, the options -www, -WWW and --HTTP of
s_server seem to be incompatible with DTLS.
More precisely, the following (with a suitable server.pem file in the
current directory) fails:
openssl s_server -dtls1 -www
openssl s_client -dtls1
The server shows many
Hi,
Using OpenSSL 1.0.1h 5 Jun 2014, a DTLS client can't negotiate ECC-based
ciphersuites with a compliant DTLS server since it fails to send the relevant
extensions mandated by RFC 4492.
% openssl s_client -dtls1 -debug
CONNECTED(0003)
write to 0x1761c50 [0x176c160] (166 bytes = 166 (0xA6))
On 10/07/2014 21:28, The default queue via RT wrote:
Everything works fine if -dtls1_1 is used instead of -dtls1.
Err, I meant works with -tls1_1 (TLS) instead of -dtls (DTLS).
Manuel.
__
OpenSSL Project
Hi,
When printing the content of a CSR with 'openssl req -text', the version is not
correct. For example, with a v1 request (generated with OpenSSL):
% openssl req -noout -text -in server9.csr | grep Version
Version: 0 (0x0)
The expected output is:
Version: 1 (0x0)
since 0
