I migrated API manager to 2.1.0 version and i receive the following error.I used the same certificate which i used for identity server and its supposed to work.How can I find out what is causing this issue?Which file can i check?
[2018-05-08 04:46:50,601] WARN - FileSystemPreferences Could not lock System prefs. Unix error code 1.
[2018-05-08 04:46:50,601] WARN - FileSystemPreferences Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
[2018-05-08 04:47:04,287] INFO - PermissionUpdater Permission cache updated for tenant -1234
[2018-05-08 04:47:09,272] ERROR - BinaryDataReceiver Error while reading from the socket.
javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:928)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
I am using custom jks called mycert.jks... I am replacing the wso2carbon.jks with mycert.jks in all the places where keystore name is used... May be there is some place which i shouldnt change or i should change?
Received fatal alert: certificate_unknown This should be be due to API Manager server couldn't verify the received certificate. (while calling the Identity Server maybe). If the received certificate is not CA signed, APIM server is unable to verify it without having their certificate in the client-truststore already.
As mentioned, you've replaced wso2carbon.jks with mycert.jks. Please make sure you've done the following as well.
Extract/import the public certificate from the new private key and add/export it in to the API Manager server's client-truststore.jks. keytool -export -alias certalias -keystore newkeystore.jks -file <public key name>.pem keytool -import -alias certalias -file <public key name>.pem -keystore client-truststore.jks -storepass wso2carbon
You have to set the same password for key store and key it self.
If the problem still persists add the SSL debug logs following this. These logs will expose more information on where and what exactly the issue is.
Related
I'm running a version 6 puppet on a utility node and when I try to connect to the puppet master from the puppet agent I get this error.
[root#utility ~]# puppet agent --test
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Info: Retrieving pluginfacts
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet:///pluginfacts: SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Info: Retrieving plugin
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could not retrieve file metadata for puppet:///plugins: SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Info: Loading facts
Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=error: certificate verify failed: [unable to get certificate CRL for /CN=utility.example.com]
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Also, the certificate on the puppet agent does not show on the puppet master when I run puppet cert list --all
Warning: `puppet cert` is deprecated and will be removed in a future release.
(location: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:370:in `run')
Since the agent is not issuing a certificate-signing request, it must already have a signed certificate. But it seems not to be a certificate that the master recognizes, therefore the master will not accept it. Possibly the agent does not accept the master's cert, either.
The master refusing service to an unrecognized agent is exactly what one would expect and want if an unauthorized node attempted to retrieve a catalog. The agent refusing to complete a connection to the master is exactly what one would expect and want if an agent's catalog request were delivered to an imposter posing as the master.
But if an authorized agent is having such a problem requesting a catalog from a genuine master that it should recognize, then you have a trust failure. This might happen, for example, if the agent's original master were replaced with a new one, or if Puppet were removed from the master and then re-installed.
If indeed that master has no cert for the agent in question, then you should be able to resolve the issue by shutting down the agent (if it is running as a daemon), then clearing out its certificates so that it generates a new one on its next run. The Puppet docs describe how this can be done (you should need only step 3, "Clear and regenerate certs for Puppet agents", and only for the affected agent).
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!
I am trying to configure remote github repo as the salt server root but it can't make the authentication successful with the pub/priv keypair. I have given the location of the keys in the /etc/salt/master file as well.
Below are the logs I am getting:
2018-11-05 01:48:32,197 [salt.utils.gitfs :1574][ERROR ][21391] Error occurred fetching gitfs remote 'git#[github-endpoint].git': failed to start SSH session: Unable to exchange encryption keys
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/salt/utils/gitfs.py", line 1552, in _fetch
fetch_results = origin.fetch(**fetch_kwargs)
File "/usr/lib64/python2.7/site-packages/pygit2/remote.py", line 405, in fetch
File "/usr/lib64/python2.7/site-packages/pygit2/errors.py", line 64, in check_error
GitError: failed to start SSH session: Unable to exchange encryption keys
I have checked the keypair and connection to the github endpoint.
I am able to sync the repo manually in the server.
I found with the same issue and I finally solved with the following steps:
I create a new ssh key: ssh-keygen -f gitfs_ssh -C 'test#example.com'
Then, I read that an empty line at the end of the private key could be fatal for libssh2, so I removed the empty lines at the bottom of the file (added by ssh-keygen at creation time) and then the new key began to work.
More info in this link
I had my new Nexus 3 repository running okay. I was able to configure some of the basic settings. Then I went through the process of enabling SSL. I used the instructions here. I also watched the video on that page, which does not give instructions that match the page.
My system info: ubuntu 14.4 with Java 8.
Install directory: /opt/nexus-3.0.0-b2016011501/
To simplify the path, I created a link to this directory: nexus -> /opt/nexus-3.0.0-b2016011501/ therefore the path to nexus is /opt/nexus
I generated my keystore as follows:
Created directory: /opt/nexus/etc/ssl
Changed to that directory and ran: keytool -keystore keystore -alias jetty -genkey -keyalg RSA -validity 3650. This generated a file called keystore. I then copied that file to keystore.jks.
Updated the following files: /opt/nexus/etc/org.sonatype.nexus.cfg added application-port-ssl=443 and added ${karaf.etc}/jetty-https.xml(this is different from the written instructions) to the end of the nexus-args=$ line. Then (this is in the video, but not the written instructions) I edited the /opt/nexus/etc/jetty-https.xml file and replaced the password in three places with the password I specified when I generated my keystore.
After this if I start nexus with ./nexus run it get the following error:
2016-01-27 02:20:41,013+0000 ERROR [jetty-main-1] *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer - Failed to start
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method) [na:1.8.0_72]
at sun.nio.ch.Net.bind(Net.java:433) [na:1.8.0_72]
at sun.nio.ch.Net.bind(Net.java:425) [na:1.8.0_72]
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) [na:1.8.0_72]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [na:1.8.0_72]
at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [org.eclipse.jetty.util:9.3.5.v20151012]
at org.eclipse.jetty.server.Server.doStart(Server.java:384) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [org.eclipse.jetty.util:9.3.5.v20151012]
at org.sonatype.nexus.bootstrap.jetty.JettyServer$JettyMainThread.run(JettyServer.java:274) [org.sonatype.nexus.bootstrap:3.0.0.b2016011501]
If it start it with sudo ./nexus run it will work but shows me the nag message saying I should not run it as root.
I have verified that my user is the owner of all the files and directories /opt/nexus
On Linux (and other unix type systems) you can't run on port numbers less than 1024 unless you are root. The best way to solve this is to run Nexus behind a reverse proxy. You can find instructions for this here:
http://books.sonatype.com/nexus-book/reference/install-sect-proxy.html
The above was written for Nexus 2.x, but the configuration needed will be the same in Nexus 3.
Regarding running as non-root as a service, there is a bug in 3.0m7 that makes this problematic:
https://issues.sonatype.org/browse/NEXUS-9437
The fix is to edit the "bin/nexus" startup script is to replace this line:
INSTALL4J_JAVA_PREFIX="su - $run_as_user -c"
With this:
exec su - $run_as_user "$prg_dir/$progname" $#
This fix will be in the next release.
Once that change is made, symlink $NEXUS_HOME/bin/nexus to /etc/init.d/nexus, then install the service. And edit "$NEXUS_HOME/bin/nexus.rc" and set the "run_as_user" appropriately.
Hi I am trying to load web page in webView pannel in JAVAFX.
I am able to load the web page whose certification is valid like google,yahoo. But unable to load invalid certification Sites.
Please suggest how can I add certification to my Web Site.
Thanks.
This is because the certificate cannot be found in default java certificates store.
Try to create java truststore with the root certificate from the "invalid certification sites". Command similar to this:
keytool -importcert -trustcacerts -alias somealias -file certificate.crt -deststorepass somePassword -destkeystore truststore.jks
Then start your java program with VM options:
-Djavax.net.ssl.trustStore="pathto\truststore.jks" -Djavax.net.ssl.trustStorePassword="somePassword" -Djavax.net.debug=all
Additional option -Djavax.net.debug=all allows you to debug the ssl handshake and see potential errors with certificates.