I am trying to remove weak ciphers from openssl ciphersuites list. When I run 'openssl ciphers -v' I see ciphers with SSLv3 and TLSv1 as well. I want to avoid weak ciphers and restrict ciphers list to only TLSv1.2 and greater.
Is there any way I can do this by updating openssl.cnf file.
I tried approaches from https://github.com/openssl/openssl/issues/7562 and https://www.openssl.org/docs/man1.1.1/man5/config.html
openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.2
With above configuration when I run 'openssl ciphers -v' command, I expect to see only TLSv1.2 and TLSv1.3 ciphers, but I see no changes in ciphers listed and all weak ciphers are also present.
We can restrict ciphers suites list by removing them from openssl code and building and installing it. Please suggest if there is any other easier way.
From openssl man pages - https://www.openssl.org/docs/man1.1.1/man5/config.html, has this statement 'The system default configuration with name system_default if present will be applied during any creation of the SSL_CTX structure.'
that means, are these openssl.conf changes applied only to certificate file generation and not to the openssl execution?
Any help or clarification of my understanding is appreciated.
We could get only required ciphers by changing openssl.cnf file.
Adding this default conf line at the top of the file
# System default
openssl_conf = default_conf
Appending below conf at the bottom of the file.
[default_conf]
ssl_conf = ssl_section
[ssl_section]
system_default = system_default_section
[system_default_section]
CipherString = ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384
Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
I used Ciphersuites to specify TLSv1.3 ciphers and CipherString to restrict other versions.
Related
Since i want to test the config of our PHPMailer i searched a whole day for a possibility to get something like a log with the config listed. I found Troubleshooting on the github page of PHPMailer where exactly that topic is described.
That is the part of the response that is interesting for me is:
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Unfortunately there is just described what command to use but not how:
In order to eliminate PHP config or your code from encryption issues, you can use your local openssl installation to test the config directly using its built-in SMTP client, for example to test an explicit SMTP+STARTTLS config:
echo QUIT | openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587
Because i have no experiences in something like unit testing and since there is nothing to find on google or on stackoverflow how to use that command i'm totally lost.
So please give me a hint. For example: should it be typed in a console on the server or should it be part of a test script or something else?
I am downloading the SSL certificate from the vCenter 6.5 and copying the certificate in a file like below.
cert = ssl.get_server_certificate((server, port))
with open(file_name, "w") as outfile:
outfile.write(cert)
later when I am using the file_name in the restAPI's , getting the error
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)
I tried to cross verify the certificate in the Shell but got the below error
# openssl verify -verbose -CAfile file_name file_name
file_name: CN = pn-a26-ub-15-7-vc.cisco.com, C = US
error 20 at 0 depth lookup:unable to get local issuer certificate
Can someone help on what went wrong on generating the certificate
The file you pass via -CAfile parameter should contain the root (and intermediate, if there is one) certificates used to issue the certificate to be verified. You seem to be passing the server certificate itself.
If this is a CA-signed certificate you can omit the -CAfile argument. If not, you should supply the issuer chain in PEM format. As far as I remember vCenter uses self-signed certificates. You may be able to download the root certificates using the method described here.
I was given a .NET Core project to run in a Linux Docker container to do the build, everything seems to be okay on the docker configuration side, but when I run this command: dotnet publish -c Release -o out, I get the SSL authentication error below.
The SSL connection could not be established, see inner exception. Authentication failed because the remote party has closed the transport stream.
I did my research and apparently it seemed that I was missing:
the environment variables Kestrel for ASPNET (as per https://github.com/aspnet/AspNetCore.Docs/issues/6199), which I add to my docker-compose, but I don't think it is the issue.
a Developer .pfx certificate, so I updated my docker-compose with the Kestrel Path to the certs file as seen below.
version: '3'
services:
netcore:
container_name: test_alerting_comp
tty: true
stdin_open: true
image: alerting_netcore
environment:
- http_proxy=http://someproxy:8080
- https_proxy=http://someproxy:8080
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=https://+;http://+
- ASPNETCORE_HTTPS_PORT=443
- ASPNETCORE_Kestrel__Certificates__Default__Password="ABC"
- ASPNETCORE_Kestrel__Certificates__Default__Path=/root/.dotnet/corefx/cryptography/x509stores/my
ports:
- "8080:80"
- "443:443"
build: .
#context: .
security_opt:
- seccomp:unconfined
volumes:
- "c:/FakePath/git/my_project/src:/app"
- "c:/TEMP/nuget:/root"
networks:
- net
networks:
net:
I re-run the docker container and executed dotnet publish -c Release -o out with the same results.
From my host I can do this to my local NuGet:
A) wget https://nuget.local.com/api/v2 without issues,
B) but from the container I can't.
C) However from the container I can do this to official NuGet wget https://api.nuget.org/v3/index.json, so definetely my proxy is working okay.
Debugging SSL issue:
The given .pfx certificate is a self-signed one, and it is working okay from Windows OS (at least I was told that).
strace shows me from where the certs are being pulled from as below
root#9b98d5447904:/app# strace wget https://nuget.local.com/api/v2 |& grep certs open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 3
I exported the .pfx as follows:
openssl pkcs12 -in ADPRootCertificate.pfx -out my_adp_dev.crt then moved it to /usr/local/share/ca-certificates/, removed the private part, just left in the file public part (-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ) executed update-ca-certificates and I could see 1 added, double checked in file /etc/ssl/certs/ca-certificates.crt and the new cert was in there.
Executed this again wget https://nuget.local.com/api/v2 and failed.
I used OpenSSL to get more info and as you can see it is not working, the cert has a weird CN, because they used a wildcard for the subject and to me this is wrong, but they state that .pfx is working in Windows OS.
root#ce21098e9643:/usr/local/share/ca-certificates# openssl s_client -connect nuget.local.com:443 -CApath /etc/ssl/certs
CONNECTED(00000003)
depth=0 CN = *.local.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.local.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=\x00*\x00l\x00o\x00c\x00a\x00l\x00.\x00c\x00o\x00m
i:/C=ES/ST=SomeCity/L=SomeCity/OU=DEV/O=ASD/CN=Development CA
---
Server certificate
-----BEGIN CERTIFICATE-----
XXXXXXXXXXX
XXXXXXXXXXX
-----END CERTIFICATE-----
subject=s:/CN=\x00*\x00l\x00o\x00c\x00a\x00l\x00.\x00c\x00o\x00m
issuer=i:/C=ES/ST=SomeCity/L=SomeCity/OU=DEV/O=ASD/CN=Development CA
---
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1284 bytes and written 358 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: 95410000753146AAE1D313E8538972244C7B79A60DAF3AA14206417490E703F3
Session-ID-ctx:
Master-Key: B09214XXXXXXX0007D126D24D306BB763673EC52XXXXXXB153D310B22C341200EF013BC991XXXXXXX888C08A954265623
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1558993408
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---
I don't know what issue I'm facing, but it appears to be that:
A) the self-signed .pfx was wrongly configured, and now that it is being used in Linux it doesn't work as it should.
B) I need some more config in the container, which I'm not aware of.
What else should I do?
I'm thinking on probaly create other cert to use from Linux hosts.
Is it feasible to create another self-signed cert with OpenSSL for IIS ver 8 and import it to IIS?.
Any ideas are welcome, cheers.
ANSWERING TO MYSELF
It was not a Linux container issue, it is a certificate issue in the web server (IIS), because we are using self-signed certificates and in this way the cert will be always an invalid certificate. Self-signed certs works okay on Windows OS side, doesn't matter the invalid error. Of course self-signed certs are just for a test environment or so.
From Linux OS when you are trying to pull packages from NuGet you will get the error below, because:
1) The cert is indeed invalid, and
2) because apparently there is not an option to ignore an invalid certificate from Linux side.
The SSL connection could not be established, see inner exception.
The remote certificate is invalid according to the validation procedure.
The solution is you are working in a corporate environment, is to request to System Administrator a proper signed certificate, for that you generate a CSR from your web server, in my case IIS, then pass it to them, so they will send you back a .cer file to install in that web server.
The other option that I was trying to do but I couldn't due to the limitations of my corporate environment, is to create a fake CA (with OpenSSL), then you sign the CSR's yourself to have some valid certificates for your Dev or test environment.
Apologizes for answering this myself, but I believe it is worth to share my findings.
Hope it helps.
I had a similar problem. Docker build would not restore my nugets.
Unable to load the service index for source https://api.nuget.org/v3/index.json.
The SSL connection could not be established, see inner exception.
Authentication failed because the remote party has closed the transport stream.
(On a Mac running Catalina)
I turned off Fiddler and then it all worked again.
I'm currently installing a Comodo certificate from Cheapssls.com. Im getting the following error:
SSL Library Error: 185073780 error:0B080074:x509 certificate
routines:X509_check_private_key:key values mismatch
Im 100% sure the privatekey and the CSR are from the same generation
Im using the follinwg syntax:
SSLEngine on
SSLCertificateKeyFile /usr/local/apache/conf/x-x-nl-new.key
SSLCertificateFile /usr/local/apache/conf/x_x_nl.crt
SSLCertificateChainFile /usr/local/apache/conf/x_x_nl.ca-bundle
which is correct im my opinion.
Anyone suggestions?
Are your key on PEM format ?
It's needed by apache : https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#SSLCertificateKeyFile
PEM is a Base64 encoded certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".
You can check it with a simple file editor
Edit1:
You can also check that the modulus are the OK for that make a diff between Cert modulus and KEY modulus with this command.
# Change KEY and CERT by your file name
diff <(openssl rsa -in KEY -modulus -noout) <(openssl x509 -in CERT -modulus -noout)
You shouldn't have any out put, If you have some, the key and the certificate don't match.
I'm connecting to a server whos cert is signed by my own CA, the ca's cert had installed into system's keychain.
connecting with openssl s_client -connect some.where says Verify return code: 0 (ok)
but i cant connect with nodejs's tls/https module, which fails with
Error: SELF_SIGNED_CERT_IN_CHAIN
but connecting to a normal server (i.e google.com:443) works fine.
seems that nodejs's openssl is not sharing same keychain with system's openssl.
but I cannt find where is it. i tried overide with SSL_CERT_DIR but not seemed working.
BTW: i can bypass the server verifying by setting NODE_TLS_REJECT_UNAUTHORIZED=0 , but that's not pretty enough ;)
Im using OSX 10.8.3 with OpenSSL 0.9.8r, node v0.9.8
The default root certificates are static and compiled into the node binary.
https://github.com/nodejs/node/blob/v4.2.0/src/node_root_certs.h
You can make node use the system's OpenSSL certificates. This is done by starting node via:
node --use-openssl-ca
See the docs for further information.
See this answer on how system certificates are extended for Debian and Ubuntu
If you're using the tls module (and it seems like you are) with tls.connect you can pass a ca param in the options that is an array of strings or buffers of certificates you want to trust.