I'm running the qtopcuaviewer example following these instructions to create the client certificate:
# create a self-signed certificate and private key
openssl req -new -x509 -config opcuaviewer.config -newkey rsa:2048 -keyout opcuaviewer.key -nodes -outform der -out opcuaviewer.der
# install the certificate and key into the application PKI directory
mv opcuaviewer.der /path/to/application/pki/own/certs/opcuaviewer.der
mv opcuaviewer.key /path/to/application/pki/own/private/opcuaviewer.pem
# secure private key file permissions
chmod 600 /path/to/application/pki/own/private/opcuaviewer.pem
Here the warnings I get:
Debug: "Creating PKI path '/home/user/bin/pki/trusted/certs': SUCCESS." (../opcuaviewer/mainwindow.cpp:399, bool MainWindow::createPkiPath(const QString&))
Debug: "Creating PKI path '/home/user/bin/pki/trusted/crl': SUCCESS." (../opcuaviewer/mainwindow.cpp:399, bool MainWindow::createPkiPath(const QString&))
Debug: "Creating PKI path '/home/user/bin/pki/issuers/certs': SUCCESS." (../opcuaviewer/mainwindow.cpp:399, bool MainWindow::createPkiPath(const QString&))
Debug: "Creating PKI path '/home/user/bin/pki/issuers/crl': SUCCESS." (../opcuaviewer/mainwindow.cpp:399, bool MainWindow::createPkiPath(const QString&))
Warning: No functional TLS backend was found (:0, )
Warning: No TLS backend is available (:0, )
Warning: No client certificate found at "/home/user/bin/pki/own/certs/opcuaviewer.der" . Application identity will be invalid. (:0, )
First issue
The certificate created with the procedure above is there and it has the correct permissions:
$ ls -l /home/user/bin/pki/own/certs/opcuaviewer.der
-rw-rw-r-- 1 user user 1143 Jan 18 14:57 /home/user/bin/pki/own/certs/opcuaviewer.der
Why does it not find it?
Second issue
The warning about TLS should imply there are some missing library for SSL. But ldd tell me nothing wrong and I have the following libraries installed:
$ dpkg -l | grep libssl
ii libssl-dev:amd64 1.1.1f-1ubuntu2.8 amd64 Secure Sockets Layer toolkit - development files
ii libssl1.1:amd64 1.1.1f-1ubuntu2.8 amd64 Secure Sockets Layer toolkit - shared libraries
$ dpkg -l | grep libk5crypto
ii libk5crypto3:amd64 1.17-6ubuntu4.1 amd64 MIT Kerberos runtime libraries - Crypto Library
Is there anything else I need to deploy?
Qt 6.2.0 under Ubuntu 20.04.
You have to deploy the TLS plugin found under:
qt-path/6.2.0/gcc_64/plugins/tls/
and it would solve both issues.
Related
It appears sometime in June of this year our SSL validation inside of Artifactory started to fail for https://files.pythonhosted.org. As a result we are no longer able to resolve remote lookups for python packages not hosted locally.
The error when I click Test on the remote repository settings page with https://files.pythonhosted.org as the hostname:
Connection to remote repository failed: Certificate for doesn't match
any of the subject alternative names:
[r.shared-319-default.ssl.fastly.net]
When I try to validate the SSL using openssl on the host linux server:
openssl s_client -connect files.pythonhosted.org:443
subject=/CN=r.shared-319-default.ssl.fastly.net
If I pass the servername flag to openssl it finds the right cert:
openssl s_client -servername files.pythonhosted.org -connect files.pythonhosted.org:443
subject=/CN=*.pythonhosted.org
How do I go about fixing this in the UI?
server: CentOS Linux release 7.7.1908 (Core)
artifactory version: EnterpriseX license 7.3.2 rev 70302900
EDIT
Appears this is most likely caused by the version of artifactory this specific instance is running. I was able to check a newer version than what this instance is running and it works correctly.
EDIT2
The system.yaml contained the following
extraJavaOpts: -Djsse.enableSNIExtension=false
this was disabling artifactory from resolving SNI enabled domains. Fixed!
I tested the reported scenario. Executing an openssl command to retrieve the certificate from the Python registry is returning certificates with a different CN apart from the expected one.
Command:
openssl s_client -showcerts -connect files.pythonhosted.org:443 </dev/null
I couldn't confirm if this is an issue with a redirect. However, executing the command to retrieve the certificate with server name in specific appears to be revealing the actual certificate for the remote site.
So, Could you please try using the following command, collect the certificate and use this certificate to replace the already amended certificates in support of this remote connection?
openssl s_client -showcerts -connect files.pythonhosted.org:443 -servername files.pythonhosted.org </dev/null
I'm not familiar with the artifactory you mentioned. But I can give you a hint on the certificate part, in general, your issue is caused by the website files.pythonhosted.org support SNI and your client-side cannot recognize the SNI support.
To check the server website ssl information, you can visit:
https://www.ssllabs.com/ssltest/analyze.html?d=files.pythonhosted.org&s=151.101.1.63
In the result, you can see a line "Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI" which means there are 2 certificates in the server, and for more explanation, you can check
https://support.cpanel.net/hc/en-us/articles/360055289933-Why-is-SSLLabs-Certificate-2-RSA-2048-bits-SHA256withRSA-No-SNI-test-showing-an-error-
And OpenSSL older version cannot handle SNI correctly as well, that's why your openssl command is not returning the expected result. Actually, the same command
openssl s_client -showcerts -connect files.pythonhosted.org:443
with OpenSSL 1.0.2k-fips on Oracle Linux 7, it returns:
r.shared-319-default.ssl.fastly.net
with OpenSSL 1.1.1 FIPS on Centos 8, it returns: *.pythonhosted.org
So the issue may be related to https://www.jfrog.com/jira/browse/HAP-556
https://www.jfrog.com/jira/si/jira.issueviews:issue-html/BI-167/BI-167.html
We have an orchestration of microservices running on a server. An nginx service is acting as a proxy between microservices. We would like to have all the communications on SSL with our self-signed certificates.
We want to add our private CA to every service (running on Debian Buster), so that it is considered valid everywhere within that service. We generate our server certificate and CA as follows:
# Generate Root CA Certificate
openssl genrsa -des3 -out CA-key.pem 2048
openssl req -new -key CA-key.pem -x509 -days 1000 -out CA-cert.pem
# Generate a Signing a Server Certificate
openssl genrsa -des3 -out server-key.pem 2048
openssl req –new –config openssl.cnf –key server-key.pem –out signingReq.csr
openssl x509 -req -days 365 -in signingReq.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out server-cert.pem
However, we can't make the microservices to consider the certificate as valid and trust it. When a get request is issued using the request library of Python in the micro-service, the following exception is thrown:
requests.exceptions.SSLError: HTTPSConnectionPool(host='server.name', port=443): Max
retries exceeded with url: /url/to/microservice2/routed/via/nginx/ (Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed: self signed certificate (_ssl.c:1076)')))
What we have tried so far:
Copying the certificate to /usr/share/ca-certificate/ and running the sudo dpkg-reconfigure ca-certificates and/or update-ca-certificates commands.
Set the REQUESTS_CA_BUNDLE env variable to /path/to/internal-CA-cert.pem
Set the SSL_CERT_FILE env variable to /path/to/internal-CA-cert.pem
The only workaround that works is setting the valid=False in requests.get(url, params=params, verify=False, **kwargs), to ignore the validity of the SSL certificate is ignored. But, this is not the worfklow we would want to implement for all the microservices and communications.
The solution was to copy the self-signed server certificate (signed with our own CA) to the /usr/local/share/ca-certificates directory and use the update-ca-certificates which is shipped in debian distributions (similar solution is available for other linux distributions).
cp /path/to/certificate/mycert.crt /usr/local/share/ca-certificates/mycert.crt
update-ca-certificates
However, the tricky part is that the above solution is not sufficient for the python request library to consider the certificate as valid. To resolve that, one has to append the self-signed server certificate to the cat-certificates.crt and then set the environment variable REQUESTS_CA_BUNDLE to that appended file.
cat /path/to/certificate/mycert.crt >>/etc/ssl/certs/ca-certificates.crt
export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
I'm new in ASP.NET.
Environment:
Ubuntu 18.04
Visual Studio Code
.NET SDK 2.2.105
I'm in trouble with some command running.
I was reading tutorial at
https://learn.microsoft.com/ja-jp/aspnet/core/tutorials/razor-pages/razor-pages-start?view=aspnetcore-2.2&tabs=visual-studio-code
and ran this command:
dotnet dev-certs https --trust
I expect https://localhost should be trusted.
but I found the error message;
$ Specify --help for a list of available options and commands.
It seems that the command "dotnet dev-certs https" has no --trust options.
How to resolve this problem?
On Ubuntu the standard mechanism would be:
dotnet dev-certs https -v to generate a self-signed cert
convert the generated cert in ~/.dotnet/corefx/cryptography/x509stores/my from pfx to pem using openssl pkcs12 -in <certname>.pfx -nokeys -out localhost.crt -nodes
copy localhost.crt to /usr/local/share/ca-certificates
trust the certificate using sudo update-ca-certificates
verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
verify if it's trusted using openssl verify localhost.crt
Unfortunately this does not work:
dotnet dev-certs https generates certificates that are affected by the issue described on https://github.com/openssl/openssl/issues/1418 and https://github.com/dotnet/aspnetcore/issues/7246:
$ openssl verify localhost.crt
CN = localhost
error 20 at 0 depth lookup: unable to get local issuer certificate
error localhost.crt: verification failed
due to that it's impossible to have a dotnet client trust the certificate
Workaround: (tested on Openssl 1.1.1c)
manually generate self-signed cert
trust this cert
force your application to use this cert
In detail:
manually generate self-signed cert:
create localhost.conf file with the following content:
[req]
default_bits = 2048
default_keyfile = localhost.key
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_ca
[req_distinguished_name]
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = localhost
commonName_max = 64
[req_ext]
subjectAltName = #alt_names
[v3_ca]
subjectAltName = #alt_names
basicConstraints = critical, CA:false
keyUsage = keyCertSign, cRLSign, digitalSignature,keyEncipherment
[alt_names]
DNS.1 = localhost
DNS.2 = 127.0.0.1
generate cert using openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -config localhost.conf
convert cert to pfx using openssl pkcs12 -export -out localhost.pfx -inkey localhost.key -in localhost.crt
(optionally) verify cert using openssl verify -CAfile localhost.crt localhost.crt which should yield localhost.crt: OK
as it's not trusted yet using openssl verify localhost.crt should fail with
CN = localhost
error 18 at 0 depth lookup: self signed certificate
error localhost.crt: verification failed
trust this cert:
copy localhost.crt to /usr/local/share/ca-certificates
trust the certificate using sudo update-ca-certificates
verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
verifying the cert without the CAfile option should work now
$ openssl verify localhost.crt
localhost.crt: OK
force your application to use this cert
update your appsettings.json with the following settings:
"Kestrel": {
"Certificates": {
"Default": {
"Path": "localhost.pfx",
"Password": ""
}
}
}
While the answer provided by #chrsvdb is helpful it does not solve all problems. I still had issue with service-to-service communication (HttpClient - PartialChain error) and also you must reconfigure Kestrel to use your own certificate. It is possible to create a self-signed certificate and import it to the .NET SDK. All you need is to specify the 1.3.6.1.4.1.311.84.1.1 extension in the certificate.
After that the cert can be imported into .NET Core SDK and trusted. Trusting in Linux is a bit hard as each application can have it's own certificate store. E.g. Chromium and Edge use nssdb which can be configured with certutil as described John Duffy. Unfortunately the location to the nssdb maybe different when you install application as snap. Then each application has its own database. E.g. for Chromium Snap the path will be $HOME/snap/chromium/current/.pki/nssdb, for Postman Snap the will be $HOME/snap/postman/current/.pki/nssdb and so on.
Therefor I have created a script which generates the cert, trusts it for Postman Snap, Chmromium Snap, current user nssdb and on system level. It also imports the script into the .NET SDK so it will be used by ASP.NET Core without changing the configuration. You can find more informations about the script in my blog post https://blog.wille-zone.de/post/aspnetcore-devcert-for-ubuntu
In adition to crisvdb answer, I've several information to add and is the continuation of the walktrough. I don't comment because is pretty complex comment this, but before this answer take a look to crisvdb answer first and then return to continue.
Take the "in detail" crisdb answer.
You can make your cert in any folder, can be or can't be in the same folder of the app.
Take openssl verify -CAfile localhost.crt localhost.crt as not optional step, mandatory. It will help.
Do not recompile or touch the code meanwhile you are doing this, in order to get first scenario clean.
If you run sudo update-ca-certificates that will answer you in wich folder the certified should be copied.
In some distributions, as Raspbian for Raspberry Pi, CA certificates are located in /etc/ssl/certs as well as /usr/share/ca-certificates/ and in some cases /usr/local/share/certificates.
Do not copy the cert manually to trusted certs, run sudo update-ca-certificates after you copy the cert in the right folder. If it doesn't work (doesn't update or add any certificate) copy it to every folder possible.
If you use a password while making the certificate, you should use it in the appsettings.json
If you get this error:
Interop+Crypto+OpenSslCryptographicException: error:2006D002:BIO
routines:BIO_new_file:system lib
Take in consideration that error means "access denied". It can be because you don't have permissions or related.
7b) Could be also that the file is not found, I use the entire path in the config:
"Path": "/home/user/www/myfolder1/myapp/localhost.pfx",
After that, and if everything works, you could see a 500 error if you are using Apache or Apache2.
If you get the following error in the apache logs of the site:
[ssl:error] [remote ::1:yourport] AH01961: SSL Proxy requested for
yoursite.com:443 but not enabled [Hint: SSLProxyEngine] [proxy:error]
AH00961: HTTPS: failed to enable ssl support for [::1]:yourport
(localhost)
you must set in the VirtualHost the following configuration after SSLEngine On and before your ProxyPass
SSLProxyEngine on
After that, and if everything works, you could see a 500 error if you are using Apache or Apache2.
If you get the following error in the apache logs of the site:
[proxy:error] [client x.x.x.x:port] AH00898: Error during SSL
Handshake with remote server returned by /
[proxy_http:error] [client x.x.x.x:port] AH01097: pass request body failed to [::1]:port
(localhost) from x.x.x.x()
you must set in the VirtualHost the following configuration after SSLProxyEngine on and before your ProxyPass
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
UPDATE
If you are renovating this, and using the same names, take in consideration that you should remove your pem file from etc/ssl/certs
UPDATE 2
If it returns:
Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:2006D002:BIO routines:BIO_new_file:system lib
Check that your pfx file is on 755 permissions.
If appsettings.json seems to be don't load (on port 5000 by default or SQL or any configuration doesn't load or can't be read), take in consideration that the dotnet must be executed on the same directory where is appsettings.json
Looks like this is a known issue with dotnet global tools and that specific command is only available for MacOS and Windows. See this issue on github: Issue 6066.
It seems like there may be a work around for Linux users based on this SO post: ASP.Net Core application service only listening to Port 5000 on Ubuntu.
For Chrome:
Click "Not Secure" in address bar.
Click Certificate.
Click Details.
Click Export.
Run: certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n {FILE_NAME} -i {FILE_NAME}
Restart Chrome.
It looks like the following could help to trust the dotnet dev certs:
https://blog.wille-zone.de/post/aspnetcore-devcert-for-ubuntu/
Then you will see also in the browser that certificate is OK and valid for the next yeat.
Give it a try...
Good luck!
When I try to create a new project in R studio by cloning a repository as follows:
File >> New Project >> Version Control >> Git >> ..enter Repository URL
I get the following error message
Cloning into 'simple-repository'...
fatal: unable to access 'https://github.com/kedemd/simple-repository/': SSL certificate problem: self signed certificate in certificate chain
Any idea why I get this/ how to fix it?
I am using R 4.2, RStudio 1.1, and Windows
You have to configure git to trust your corporate self-signed certificate.
The way to do it is explained in this answer. In substance:
1) Get the certificate:
openssl s_client -connect repos.sample.com:443
Catch the output into a file cert.pem and delete all but part between (and including) -BEGIN CERTIFICATE- and -END CERTIFICATE-
2) Configure git to trust this certificate
git config --global http.sslCAInfo /path/to/cert.pem
Read the original answer for full details.
I'm trying to start the Java WS Core container version 4.0.8 from the Globus Tooklit. Before I can start the container, I need to create a grid proxy using grid-proxy-init. I am using my CERN certificate for this purpose. I have also downloaded the CERN Root CA and the CERN Trusted Certificate Authority certificates and configured globus to trust them. However, when I do grid-proxy-init, I get the following error:
Files used:
proxy : /tmp/x509up_u501
user key : ~/.globus/userkey.pem
user cert : ~/.globus/usercert.pem
Your identity: (correct identity)
Error: Wrong pass phrase
java.security.InvalidKeyException: Algorithm not supported.
at org.globus.gsi.OpenSSLKey.readPEM(OpenSSLKey.java:169)
at org.globus.gsi.OpenSSLKey.<init>(OpenSSLKey.java:105)
at org.globus.gsi.bc.BouncyCastleOpenSSLKey.<init>(BouncyCastleOpenSSLKey.java:45)
at org.globus.tools.DefaultProxyInit.loadKey(ProxyInit.java:608)
at org.globus.tools.ProxyInit.createProxy(ProxyInit.java:204)
at org.globus.tools.ProxyInit.main(ProxyInit.java:518)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95)
at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37)
Please note that my CA certificates are in a non-standard location (~/.globus/certificates). I've tried using X509_CERT_DIR=~/.globus/certificates, but to no avail. Also, grid-proxy-init doesn't actually ask me for a passphrase. It just gives that error. I have no idea how to debug this further. I would appreciate any ideas about how to procee. Also, I would like to verify that globus is indeed recognising my CA certificates without any problems. Thanks!
Ok so I figured out what the problem was. I was converting the certificate to PEM from PKCS using:
openssl pkcs12 -in cert.p12 -out usercert.pem -nokeys
openssl pkcs12 -in cert.p12 -out userkey.pem -nocerts -nodes
Apparently this only extracts the private key from the certificate file but does not actually convert it to PEM format. For that I had to use the following command:
openssl pkcs12 -in cert.p12 -nocerts -nodes|openssl rsa -out userkey.pem -des3
This outputs the private key in the required format and grid-proxy-init works fine now.