The problem is that the OpenID Connect URL I'm trying to reach uses self-signed certs. The plugin securityDashboards doesn't seem to like that:
Error: unable to verify the first certificate\ n at TLSSocket.onConnectSecure(_tls_wrap.js: 1088: 34)\ n at TLSSocket.emit(events.js: 198: 13)\ n at TLSSocket._finishInit(_tls_wrap.js: 666: 8)\ n code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
...
Client request error: unable to verify the first certificate
Since this seems to be a JavaScript error, my first approach was to point npm to the same keystore which also curl uses and which has no problem with the URL. Via npm config set cafile /etc/ssl/certs/ca-certificates.crt
After that didn't work I tried to disable the SSL verification altogether just to see if it works. Via npm config set strict-ssl false
That failed so I read the docs about certificate validation, tried to set up pemtrustedcas_filepath with the keystore above... didn't work.
Then tried to download the cert and use pemtrustedcas_content, but that didn't work either.
Out of options. Thanks for any suggestion!
Setting opensearch_security.openid.root_ca: /etc/ssl/certs/ca-certificates.crt in opensearch_dashboards.yml worked for me.
Related
Is it possible to have Wazuh Manager served through custom SSL certificates? The wazuh-certs-tool gives you a self cert, and every other way to get it served through SSL has failed.
The closest I've gotten to getting this to work is I've had the dashboard being served by a custom SSL, I had agents connecting to it successfully and providing a heartbeat, but had zero log flows or events happening. When I had it in this state, I saw the API calls were coming from what appeared to be a Java instance, erroring out complaining about receiving certificate. I saw a keystore file located at /etc/wazuh-indexer. Do I also need to add the root-ca cert here as well?
It seems that your indexer's excepted certificates do not match the certificates in your manager or the dashboard.
If you follow the normal installation guide, it shows how and where to place your certificates, that are created using the wazuh-cert-tool. But, certificates can be created from any other source, as long as they have the expected information, you can check that informationenter link description here here.
I would recommend you follow the installation steps in the installation guide, from scratch to make sure you copy each excepted certificate in it's place and that the configuration files for your indexer, dashboard, and manager take into account the correct files. All you would need to change, the creation of the certificates, to have your own custom certs.
In case of further doubt, do not hesitate to ask.
I have followed the getting started instructions here: https://linkerd.io/2/getting-started/ for installing linkerd but i am not able to install cli of linkerd.
Please see the command below: curl -sL https://run.linkerd.io/install | sh
Please see the error below:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option
Can anyone please help me to solve it.
The provides installation instructions from the Linkerd website are indeed vague, they provide instruction for Linux (shell) users as well as a brew install command for OSX users.
If you are interested in installing LinkerD on your Windows machine, the recommandation is to download the binary (.exe - for Windows) directly form their release page: https://github.com/linkerd/linkerd2/releases
After you have downloaded the binary, you should be able to update your %PATH% environment variable to add the location of the binary, this will allow you to refer to the linkerd directly from your command prompt.
Linkerd started supporting Windows with a Chocolatey package: https://chocolatey.org/packages/Linkerd2
To use it, make sure that you have Chocolatey installed and run:
choco install linkerd2
After the installation, verify that the install was successful with:
linkerd --help
You should see the list of commands available to the Linkerd CLI.
pkg set-publisher: The origin URIs for 'solarisstudio' do not appear to point to a valid pkg repository.
Please verify the repository's location and the client's network configuration.
Additional details:
Unable to contact valid package repository: https://pkg.oracle.com/solarisstudio/release
Encountered the following error(s):
Transport errors encountered when trying to contact repository.
Reported the following errors:
Framework error: code: 60 reason: SSL certificate problem: unable to get local issuer certificate
URL: 'https://pkg.oracle.com/solarisstudio/release'
1.Make sure that ca-certificates service is running on solaris
svcs -xv
if not try starting using the below commands
svcadm disable svc:/system/ca-certificates:default
svcadm enable svc:/system/ca-certificates:default
Make sure that the below permission is set for all the certificates
If the above solution doesnot work
2. Take backup of all the certificates under /etc/certs/CA. Check for the corrupted certificates, by moving the certificates one by one to /etc/certs/CA in the location and starting ca-certificate service. The point when the service doesn't start is the certificate which is corrupted.
Make sure that the certificates in the location have below permissions
sudo chown root:sys /etc/certs/CA/*.pem
When generating certificate via directadmin using letsencrypt for mail.domain.com, directadmin told me that it generated a certificate called:
letsencrypt.key
But in order to make the mail.domain.com contains the certificate, I have to edit the dovcot config like below:
ssl_cert = </etc/letsencrypt/live/YOURSITE/fullchain.pem
ssl_key = </etc/letsencrypt/live/YOURSITE/privkey.pem
But as shown above dovcot only take 2 parameters for certs and I only have letsencrypt.key
How do I point this certificate in dovcot so, that it will use let's encrypt certs ?
UPDATE:
I read that the built-in feature letsencrypt in DA actually combined the cert into one. I search Google and redirected to a site that we can manually install the DA letsencrypt so that it will generate 3 files for certs where I can use to link in dovcot.
So in order to do this do I have to disable the built in feature of DA Let's encrypt?
The URL: https://www.interserver.net/tips/kb/letsencrypt-support-directadmin-control-panel/
Is this the best way? What about the renewal process? Will directadmin handle the cert's renewal process or we need to create cronjob for that ? I'm lost.
My aim is just to enable certificate for the mail.domain.com (using let's encrypt) so when I log in using 3rd party email client, it would not complain about invalid certs.
I never heard about mail_sni someone pointed out that I should use this to make it work. Following this documentation, everything is working:
http://forum.directadmin.com/showthread.php?t=56297
Amazon recently release Echo Alexa toolkit.
I received, registered my app. Alexa clearly recognizes my app exists. However it gives this error
Request Identifier:
amzn1.echo-api.request.d969c196-8b3e-4169-99c8-20f566889760 The
certificate does not have a path to a trusted authority. This happens
if you are using a self signed certificate. Voice feedback Echo heard:
"alexa start myapp"
I verified my COMODO CA (COMODO RSA Certification Auth) is on the list of authorized CA. I ensured my certificate bundle was valid.
Is there anything specific I need to ensure my bundle.crt is in the correct order for Alexa? (there is no mention that .com is required, I am using .net)
these my COMODO filenames.
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
mydomain-net.crt
ssl-bundle.crt
stn.private.key
Excited to get this to work ... please help
SA
I am now able to communicate with Alexa without issues. the source of the problem was the order of the certs and the incorrect directives in SSL and HTTP config files for apache.
I used
openssl s_client -connect 192.237.1.1:443
to verify that the certificate
Verify return code: 0 (ok)
Initially I was able to confirm the error by code and searched and fixed it.