Force using TLS v1.3 - ssl

Im trying to use TLS v1.3 by setting following options:
opts->tls_ctx = SSL_CTX_new(TLS_client_method());
SSL_CTX_set_options(opts->tls_ctx, SSL_OP_NO_SSLv2);
SSL_CTX_set_options(opts->tls_ctx, SSL_OP_NO_SSLv3);
SSL_CTX_set_options(opts->tls_ctx, SSL_OP_NO_TLSv1);
SSL_CTX_set_options(opts->tls_ctx, SSL_OP_NO_TLSv1_1);
SSL_CTX_set_options(opts->tls_ctx, SSL_OP_NO_TLSv1_2);
The used version is v3 an as I get the following error:
SSL_connect failed (sslv3 alert handshake failure).
What am I doing wrongly that even though SSL_OP_NO_SSLv3 is set v3 is selected ?
Thank you!
I tried to disable TLSv3, TLSv2, TLSv1, TLSv1_1 and TLSv1_2 to enforce using of TLSv1_3, but TLSv3 was selected
Later Edit:
I used:
opts->tls_ctx = SSL_CTX_new(TLS_client_method());
SSL_CTX_set_min_proto_version(opts->tls_ctx, TLS1_3_VERSION);
But still TLSv1_2 is used in Client Hello, what might be still wrong ?
enter image description here

Related

EJBCA: Authorization Denied Admin GUI

I am attempting to upgrade EJBCA.
I attempted to run this on ubuntu 20.04, locally, using wildfly 18. Wildfly 18 results in this error: "CAUSE: Client certificate or OAuth bearer token required."
I have tried this two ways, by importing the keystore, truststore and superadmin from another instance and by creating the CA fresh and using the resulting superadmin.p12.
The home page loads, but the administration gives me the following error:
"AUTHORIZATIONDENIED
CAUSE: Client certificate or OAuth bearer token required. "
I can really use some help with this.
Things I have tried:
(1) I have downloaded superadmin.p12 and imported it into my browsers
(2) I have attempted to upload the superdmin cert:
bin/ejbca.sh ca importcacert ${NAME} ${NAME}.cacert.pem -initauthorization -superadmincn SuperAdmin
This results in The CA certificate is already imported.
(3) Both my keystore.jks and truststore.jks are moved into /ejbca/p12 and /opt/wildfly/standalone/configuration/keystore
(4) I did set "web.reqcertindb=false"
(6) I did try to enable ssl on wildfly 14 (https://docs.bitnami.com/bch/infrastructure/wildfly/administration/enable-ssl-wildfly/)
(7) I have tried a fresh Management_CA as well
The log of /ejbca/adminweb:
"08:20:01,270 ERROR [org.ejbca.ui.web.admin.configuration.EjbcaJSFHelperImpl] (default task-4) org.cesecore.authentication.AuthenticationFailedException: Client certificate or OAuth bearer token required.
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl] (default task-4) Language was not initialized for this session
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl]
I can provide more information if needs be.
Thank you
So, I have it running today. Here is what I learned:
It seems that if you set wildfly up as a service (per instructions) it is going to set up wildfly to run with launch.sh. Launch.sh is going to result in a cipher mistmatch. I needed to run the standalone.sh file instead
Adminweb must be contacted on 8443
if you need to run this thing on domain setup your going to need to post another question
Best,

WebSocketpp handshake issue with TLS

I have been learning with WebSocket++ and built some of the server examples (Windows 10 Visual Studio 2019). The non-TLS examples work without issues, however, the TLS-enabled examples (echo_server_both.cpp and echo_server_tls.cpp) can't do the handshake. I am very new to web development in general so I know I must be doing something wrong with regards to the certificate and keys.
I am testing the servers with WebSocket King client, an extension of Google Chrome that connects correctly to other websocket servers like wss://echo.websocket.org and to my own localhost when I don't use TLS.
The echo_server_both example comes with a server.pem file, and the echo_server_tls example comes with server.pem and dh.pem. I have used the same files that come with the samples, and I have also tried generating and registering my own .pem files using openSSL. In both cases I get this when the client tries to connect:
[2021-06-29 20:51:21] [error] handle_transport_init received error: sslv3 alert certificate unknown
[2021-06-29 20:51:21] [fail] WebSocket Connection [::1]:63346 - "" - 0 asio.ssl:336151574 sslv3 alert certificate unknown
[2021-06-29 20:51:21] [info] asio async_shutdown error: asio.ssl:336462231 (shutdown while in init)
I discovered these errors after I edited handle_init() in tls.hpp, following a suggestion in another site, to look like this:
void handle_init(init_handler callback,lib::asio::error_code const & ec) {
if (ec) {
//m_ec = socket::make_error_code(socket::error::tls_handshake_failed);
m_ec = ec;
} else {
m_ec = lib::error_code();
}
callback(m_ec);
}
This change let the actual openSSL error to show in the console, otherwise it would show a generic "handshake failed" error.
I know I'm not doing what I should with the certificates, but I have no idea where else to look or what to do next. Can anyone here help please? Should I use the .pem files that come with the examples, or should I generate my own? in case I should generate my own, what would be the openSSL command to do that correctly and how do I tell my PC to recognize these as valid so that the server works?
Found the problem: WebSocket++ will not accept a self-signed certificate (the ones you can create directly in your own PC using OpenSSL or the Windows utilities). There is no way around it. You must have a valid, authority-validated and endorsed certificate. You can get such a certificate for free (valid only for 90 days) from https://zerossl.com/. The site has detailed instructions on how to request, obtain and install a certificate. After getting a valid certificate and installing it on my server, everything worked as it should.

Erlang SSL - Certificate not suitable on sni_fun callback

I got this error:
SSL: hello: ssl_handshake.erl:171:Fatal error: internal error - server_has_no_suitable_certificates
when supplying a der-decocded certificate for the callback function in the {sni_fun, CallbackFun} option. The CallbackFun returns [{cacerts, [Cert]}], where Cert is der-encoded. So things comply with Erlang ssl module's documentation.
I tried look into the otp source code. It seems that whatever the callback returns is ignored, thus causing this function clause to be evaluated:
certificate_chain(undefined, _, _) ->
{error, no_cert};
which leads to that error! But I could be wrong as I kind of lost in browsing the code base...
If it helps, I use a self-signed CA to sign CSRs that are generated as a SNI is found during a TLS handshake (via sni_fun option).
please advise! thanks a lot!
Update:
I tried Erlang OTP 20.3 release and get another error:
TLS server: In state hello at tls_connection.erl:739 generated SERVER ALERT: Fatal - Handshake Failure - malformed_handshake_data
Looking at OTP source code, it is result of an exception from this block:
try
Version = ssl_handshake:select_version(tls_record, ClientVersion, Versions),
case ssl_cipher:is_fallback(CipherSuites) of
true ->
Highest = tls_record:highest_protocol_version(Versions),
case tls_record:is_higher(Highest, Version) of
true ->
?ALERT_REC(?FATAL, ?INAPPROPRIATE_FALLBACK);
false ->
handle_client_hello(Version, Hello, SslOpts, Info, Renegotiation)
end;
false ->
handle_client_hello(Version, Hello, SslOpts, Info, Renegotiation)
end
catch
_:_ ->
?ALERT_REC(?FATAL, ?HANDSHAKE_FAILURE, malformed_handshake_data)
end.
I am sure the cert is fine, I could view it as well as convert it between DER/PEM formats with openssl with no error. Is there a way to reveal what kind of exception it is in this case?
I solved the problem: the sni_fun must return the list of
[{cert, DerdecodedCert}, {keyfile, PathToTheCsrKeyFile}]
I was returning only
[{cert, DerdecodedCert}]
(which was so instructed by Erlang ssl doc)
Hope this helps anyone who bumps into similar problem as I did!

ERROR: Fetching the page failed because other errors. Twitter Cards Issue

When I go to https://cards-dev.twitter.com/validator and enter https://piktoria.com/blog/instagram-to-drive-sales/ and adlatch.com
Validator says - Unable to render Card preview
ERROR: Fetching the page failed because other errors.
So because of that when i share anything on twitter, don't get any snippets, tried twitter support they say:
"There's something wrong with your SSL setup - I am seeing SslHandshakeException: handshake alert: unrecognized_name at remote address in my debug log which I suspect means that your server name does not match the certificate, or something similar."
Can anyone help in solving this issue
This problem happened with me also But i managed to Fix It when twiiter told me to check SSL Settings
I got the point The problem was From AES256 and AES128 (For NgiNx Web Server) You need to enable AES128
Here is Snippet
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384!AES128:!3DES';
As you see in the Snippet the AES128 is Disabled(!)
you need to remove the ! From AES128 So the Code will be:
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:!3DES';
This might be a post a bit old, but you can get this error due to a different TLS configuration.
When I looked into my webserver error logs, I encountered the following error:
2021/05/12 19:41:31 [crit] 16585#16585: *44673 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: X.X.X.X, server: X.X.X.X:443
It looks like twitter, as of now, does not support TLSv1.3 for getting the cards, and the solution is to also enable TLSv1.2. If you use the intermediate configuration from Mozilla's ssl-config tool that is good enough.
See https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1d&guideline=5.6

CouchDB 1.6.1 SSL error on Raspbian

I am trying to setup SSL in CouchDB 1.6.1 on Raspbian and I get that :
** {badarg,[{ets,select_delete,
[undefined,[{{{undefined,'_','_'},'_'},[],[true]}]],
[]},
{ets,match_delete,2,[{file,"ets.erl"},{line,655}]},
{ssl_pkix_db,remove_certs,2,[{file,"ssl_pkix_db.erl"},{line,221}]},
{ssl_connection,terminate,3,
[{file,"ssl_connection.erl"},{line,934}]},
{tls_connection,terminate,3,
[{file,"tls_connection.erl"},{line,326}]},
{gen_fsm,terminate,7,[{file,"gen_fsm.erl"},{line,595}]},
{gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,517}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]}
My version of erlang is Erlang/OTP 17 [erts-6.2].
My local.ini file contains :
httpsd = {couch_httpd, start_link, [https]}
[ssl]
port = 6984
cert_file = /etc/couchdb/cert/couchdb.crt
key_file = /etc/couchdb/cert/couchdb.key
Http works fine. Any idea?
Cheers.
This looks like the crash fixed by this pull request, merged into Erlang/OTP 18.2.
To the best of my knowledge, the crash itself is harmless: it occurs during connection termination, because the code is trying to clean up something that never was set up. However, it might draw your attention from other errors happening before it, such as incorrect path to key / certificate files.