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.
Related
I'm trying to add PayPal payments in a Prestashop (v1.7.3) store using the PayPal & Braintree Official Module (v3.11.6), but until now without success.
Installed and configured the module without any problems, but every time i proceed with a payment this error is displayed to the user:
Tested the module in both sandbox and production environments, and the error still persists.
What can be the problem?
UPDATE: After some debugging i found the origin of the problem. The problem is that the module is unable to connect to PayPal's API via cURL with SSL/TLS.
I'm using Prestashop in Windows Server with IIS, and in this environment cURL has to be informed where the certificate authority is located in order to establish a secure connection.
I downloaded the cacert.pem file from curl website, stored it in my server and then, in module files (PPHtmlConfig.php) i added the CA location in the cURL options settings manually:
CURLOPT_CAINFO => 'C:\\(...)\\cacert.pem',
Now i'm able to connect to PayPal's API and successfully make a payment!
I've contacted the module's tech support team and they are analysing this issue.
After several contacts with the module tech support, this is their final response to the issue:
We do not know the specialty of your server. This is not a recurring
error in our module. It happens if the CURL can not find the CA
certificate. In general, we advise you to ask your server to verify
that the CA certificate is correctly configured. Otherwise, it is
necessary to specify the route or curl to find the certificate, for
example, as you did in your module.
At the moment there is no way to specify this in our module in
general. So, you should wait for the next update of our Paypal module.
So, if someone comes across the same issue when using a Windows Server environment, specify the complete CA path in the module files (as explained in the question update):
I downloaded the cacert.pem file from curl website, stored it in my
server and then, in module files (PPHtmlConfig.php) i added the CA
location in the cURL options settings manually:
CURLOPT_CAINFO => 'C:\\(...)\\cacert.pem',
WMF 5.1 includes new functionality to allow signing of MOF documents and DSC Resource modules (reference). However, this seems very difficult to implement in reality -- or I'm making it more complicated than it is...
My scenario is VMs in Azure and I'd like to leverage Azure Automation for Pull DSC Server; however, I see this applying on premise too. The problem is that the certificate used to sign the MOF configurations and/or modules needs to get placed on the machine before fetching and applying the configuration otherwise configuration will fail because the certificate isn't trusted or present on the machine.
I tried using Azure KeyVault to bootstrap the certificate (just the public key because that's my understanding of how signing works) and that fails using Add-AzureRmVMSecret because the CertificateUrl parameter expects a full certificate with the public/private key pair to install. In an ideal world, this would be the solution but that's not the case...
Other ideas, again in this context, would be to upload the cert to blob storage, use a CustomScriptExtension to pull down the cert and install into the LocalMachine store but that feels nasty as well because, ideally, that script should be signed as well and that puts us back in the same spot.
I suppose another idea would be to first PUSH a configuration that downloaded and installed certificates only but that doesn't sound great either.
Last option would be to rely on an AD GPO or something similar to potentially push the certificate first...but, honestly, trying to move away from much of that if/when possible...
Am I off-base on this? It seems like this should be a solvable problem -- just looking for at least one "good" way of doing it.
Thanks
David Jones has quite a bit of experiencing dealing with this issue in an on-premises environment, but as you stated the same concepts should apply for Azure. Here is a link to his blog. This is a link to his GitHub site with a PKITools module that he created. If all else fails you can reach out to him on Twitter.
While it's quite easy to populate a pre-booted image with public certificates. it's not possible (that I have found) to populate the private key.
DSC would require the private key to decrypt the passwords.
The most common tactic people blog about is to use the unattend to script the import of a PFX. issue there is you have to leave the password for the PFX in plain text. Perhaps that is ok in your environment.
The other option requires a more complicated setup. Use a simple DSC or GPO to auto enroll a unique certificate. then have the system, via first boot script or DSC custom resource, tickle an API (Like Polaris) and that triggers a DSC script that uses PKITools or other script to get the public certificate that the machine has. Then have that API push a new DSC config (or pull settings) to the machine.
Could somebody please point me in the right direction for configuring Hyperledger Fabric to use a custom CA. The docs here suggest that any CA that support ECDSA can be used.
Take a look at the Cryptogen tool.
It produces x509 certificates, and this can be used by you to prime the fabric network entities (orderer, peers, clients).
I recommend you run cryptogen to produce the needed PEM files by reading byfn (take a look at ./byfn.sh -m generate )
If you can replicate this folder structure you're good to go.
Additionally (this is just a thought, never tried it), Fabric-CA has an HTTP API for registering clients.
If you build your own gateway that mocks Fabric-CA's API and does the same things - you can make the client SDK (which includes also a fabric-ca client) talk with your CA as if it was Fabric-CA
I don't understand very well the aim of your question. However, I'm going to answer it.
right direction for configuring Hyperleger Fabric to use a custom CA
Hyperledger Fabric needs some certificates to control and restrict the acces to the Blockchain. For each channel you define who members are going to be part of it, and you configure the MSP. The certificates are used for the MSP. So, you can create those certificaes in any way, then you should pass them to the corresponding members and locate them in the corresponding directories.
However, Hyperledger Fabric gives you the chance to achieve it:
On the one hand, as #yacovm said, by using the cryptogen tool
On the other hand, as you said, by creating your own CA Authorithy, i.e. by your own CA Server
FOR DEVELOPMENT: I configured my site to run without SSL for my development box and it all works great.
Now I am moving this to our dev testing server so I can test it there.
I first ran it as a non ssl intranet site to confirm configuration and etc....
It works perfectly.
Now I am in the process of creating a cert for the site and plan to use self signed certs for developer testing.
I have read many post ( google search ) on the topic related to the error I am getting.
Basically, I am 110% sure I am not creating this cert correctly for the site to which I need to bind it to.
The error:
The remote certificate is invalid according to the validation procedure.
So I am trying to understand what they mean by answers like this:
When working with self-signed certificates: add them to the trusted root authorities & use the hostname instead of localhost. ]
So if your computer name is "mypc", the uri should be "https://mypc/..." instead of "https://localhost/...".
This is what is confusing to me...
For example , if computer name is: svr-d-web-003
So the uri: https: //svr-d-web-003/?????
Looking at the advanced settings Bindings could I extrapolate the uri as: https: //svr-d-web-003/webhost.oauth.xyz.org ?? This seems wrong to me...
Site settings and etc....
Used these steps to create the cert:
1. C:> certlm.msc
2. Right-click on Certificates, then click All Tasks/Request New Certificate
Click Next, Next
Click on link as shown under the template you need.
Select Common Name from drop down
Enter the machine name dns name (example: svr-v-wus-001), then click Add button
Click OK,
In the Requests Certificates window check the box for xyz, click Enroll
Look in the certificates store and it’ll be there – you may need to click Refresh button
Follow up In IIS – you’ll bind the certificate there to your site. Remember the name needs to match the url. (This might be my issue here...)
See attachment...
I finally got it to work.
When creating the cert I had to match the name of the cert (common name) to the site.
For example: the site is https://identService.oauth.xyz.org so the cert name needed to be identService.oauth.xyz.org.
Then it all worked. I was confusing the site name with the machine name. Doh...
Good morning fellas !!
I have a question regarding WS-FEDERATION.
We have a partner (IDP initiated and SP Hosted) that is configured with WS-FEDERATION.
They use ADFS and we use OPENAM (we are the SP)
Everything is set up fine and running smoothly.
But their certificate is going to expire soon and we have to update it.
So from what I saw here what we are suppose to do :
Export the SP and IDP metadata , replace the X509 Certificate value with the new one then import those configuration back.
Is that correct ?
I am using OPENAM, and they have the ssoadm command mapped with a GUI.
So I exported both of those metadata, I replaced the certificate value and we will re-import them with the partner at the same time.
I never did that change, and I want to make sure that it is the proper way and that I am not missing anything !
Thank you for the help :) :)
In this situation you will find that ADFS has interim phases i.e.
Old certificate
Old and new
New
During the middle phase, you need to get the ADFS metadata and re-import into OpenAM.
That way there will be no down time as both certificates are catered for.
If you wait until the third phase, there will be some downtime until you have done the new import.