I am trying to use ldaps to verify connections to an Impala database with the following configuration in the Impala Command Line Argument Advanced Configuration Snippet configuration item in Cloudera Manager:
--enable_ldap=true
--ldap_uri=ldaps://testServ.domain.com
--ldap_ca_certificate="/home/impala/testServ.domain.pem"
Where testServ.domain.pem is the ldap server certificate.
Using wireshark I can see that after receiving the certificate during SSL negotiation Impala always responds with an Unknown CA alert.
I can successfully connect with Impala using unencrypted ldap and I can connect with a different ldaps enabled program using the provided certificate, so I doubt the issue is on the ldap server.
Is there another configuration parameter I need or a way to determine why Impala always rejects the ldap servers certificate?
Related
I am using .NET 6 to try to make to work the default gRPC service that is created when I create a new gRPC project for ASP.
To test if I can connect to the service, I use grpcui.
I can connect when I don't use certificates, connecting to the http address, but when I try to use a certificate, using the https address, I get the error:
Cannot validate certificate for x.x.x.x because it doesn't contain any IP SANs.
I guess that is because I don't create the server certificate in the correct way, because I have to set the IP in the field SAN, but I don't know how.
What I did it is to set as CN the IP of the server, but it seems that this is not the correct place to set the IP.
So I would like to know what is SAN and how I could create the certificates with this field.
I have written my own code to connect to Firebase via the REST interface. Recently I have been unable to connect to firebaseio.com because the secure connection cannot be established with the CA certificate I am using.
I am still able to create a secure connection to googleapis.com to handle the login authentication and get the tokens I need for communication.
How do you determine what certificate is needed to validate the connection? I have tried a few of the root CA certs available at https://pki.goog/repository/ but they do not seem to work for firebaseio.com.
WireShark to the rescue! I was able to see the name of the certificates being passed to my device. Firebaseio.com is using one of the certs in this list that I had not tried yet.
After adding that one I was able to connect. How often does Firebase change these certificates? What is the proper method to keep my device up to date with the latest certificates?
I am trying to add DataPower 7.7 into API Management 2018.1.
I need to configure API Connect Gateway Service in DataPower (new APIC 2018.1 doesn't work with XML Management Service).
After configuration I got an error:
8:07:19 mgmt notice 959 0x00350015 apic-gw-service (default):
Operational state down
8:07:19 apic-gw-service error 959 0x88e00001 apic-gw-service
(default): Unexpected queue error: Domain check failed! Please ensure that
the 'default' domain exists and is enabled. Also, please verify that the API
Gateway Service is configured with the correct domain and SOMA credentials.
8:07:19 apic-gw-service error 959 0x88e000a0 apic-gw-service
(default): Failed to initialize gateway environment: datapower
DP version is 7.7.
Please suggest, if you have any information or manuals.
Note: Domain exists, main services are enabled
It's hard to tell what exactly the problem is based on the log messages shown above.
Update to original answer:
See also the documentation that is now available in the IBM API Connect Knowledge Center: https://www.ibm.com/support/knowledgecenter/SSMNED_2018/com.ibm.apic.install.doc/tapic_install_datapower_gateway.html
However, here are the basic steps for configuring a DataPower gateway to work with API Connect 2018.x.
You will need to ensure:
DataPower is running DP 7.7.0.0 or higher.
You have the AppOpt license installed. (Use the “show license” command in the DataPower CLI to confirm.)
You have a shared certificate and a private key for securing the
communication between the API Connect management server and the
gateway.
On DataPower, you need to:
Create an application domain. All of the subsequent configuration should be done in the application domain.
Enable statistics
Upload your private key and shared certificate to the cert:// directory in the application domain.
Create a crypto key object, a crypto certificate and a crypto identification credentials object using your key and certificate.
Create an SSL client profile and an SSL server profile that reference the crypto identification credential object.
Configure a gateway-peering object.
Configure and enable the API Connect Gateway Service in the application domain.
At that point, you should be able to configure the gateway in the API Connect cloud manager.
Here are the DataPower CLI commands to create a basic configuration. In the configuration below, IP address 1.1.1.1 represents a local IP address on your DataPower appliance. Traffic from the API Connect management server to the gateway will be sent to port 3000. API requests will go to port 9443 (but you can change it to the more standard port, 443, if you prefer.)
For a production environment, you will want to build on this configuration to ensure you are running with at least 3 gateways in the peer group, but this will get you started.
Create the application domain called apiconnect
top; configure terminal;
domain apiconnect; visible default; exit;
write mem
Use the Web GUI to upload your private key and shared certificate to the cert:// folder in the apiconnect domain
Then run these commands to create the configuration in the apiconnect domain
switch apiconnect
statistics
crypto
key gw_to_apic cert:///your-privkey.cer
certificate gw_to_apic cert:///your-sscert.cer
idcred gw_to_apic gw_to_apic gw_to_apic
ssl-client gwd_to_mgmt
idcred gw_to_apic
no validate-server-cert
exit
ssl-server gwd_to_mgmt
idcred gw_to_apic
no request-client-auth
validate-client-cert off
exit
exit
gateway-peering apic
admin-state enabled
local-address 1.1.1.1
local-port 15379
monitor-port 25379
priority 100
enable-ssl off
enable-peer-group off
persistence local
exit
apic-gw-service
admin-state enabled
local-address 0.0.0.0
local-port 3000
api-gw-address 0.0.0.0
api-gw-port 9443
v5-compatibility-mode on
gateway-peering apic
ssl-server gwd_to_mgmt
ssl-client gwd_to_mgmt
exit
write mem
The problem you are seeing is an issue with creating your api connect service in the default domain. To work around just put your Api Gateway Service in a domain other than default.
Is there a way to automatically deploy a .NET/Windows based Amazon Elastic Beanstalk instance with an SSL cert?
I already have the DNS for the domain in the SSL cert setup to point to the Beanstalk instance.
I can remote in and configure the server manually but I was wondering if there is a way to make it part of the deployment package (similar to what Windows Azure has).
If this isn't built in to Elastic Beanstalk, are there any hooks to run PowerShell scripts after deployment (or update) of my instance?
The AWS Elastic Beanstalk Developer Guide explains how to enable an SSL certificate for your Elastic Beanstalk environment.
The relevant part is:
Controlling the HTTPS port
Elastic Load Balancing supports the HTTPS/TLS protocol to enable
traffic encryption for client connections to the load balancer.
Connections from the load balancer to the EC2 instances are done using
plaintext. By default, the HTTPS port is turned off.
To turn on the HTTPS port
Create and upload a certificate and key to the AWS Access and Identity Management (AWS IAM) service. The IAM service will store the
certificate and provide an Amazon Resource Name (ARN) for the SSL
certificate you've uploaded. For more information creating and
uploading certificates, see the Managing Server Certificates section
of Using AWS Identity and Access Management.
Specify the HTTPS port by selecting a port from the HTTPS Listener Port drop-down list.
In the SSL Certificate ID text box, enter the Amazon Resources Name (ARN) of your SSL certificate (e.g.,
arn:aws:iam::123456789012:server-certificate/abc/certs/build). Use the
SSL certificate that you created and uploaded in step 1. For
information on viewing the certificate's ARN, see Verify the
Certificate Object topic in the Creating and Uploading Server
Certificates section of the Using IAM Guide.
I need to install a certificate for encryption (replication) between an external vendor and my company.
I cannot get a third party certificate for the FQDN of my server because the net part of that does not match a domain that we own (ie my FQDN is sqlservername.company.root.net but we don't own a domain called company.root.net.). We do own mycompany.com, so I got sqlserver.mycompany.com on the cert and have a DNS entry to alias sqlserver.mycompany.com to sqlservername.company.root.net.
I cannot use a self generated cert since the vendor needs to trust the cert authority.
I have a cert that I have purchased and installed, but SQL Server won't see it since the FQDN doesn't match.
I tried installing it by putting the thumbprint of the cert into the registry directly, but then SQL server won't start with the following errors:
The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030e. Check certificates to make sure they are valid.
Unable to load user-specified certificate [Cert Hash(sha1) "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
(where the x's above match the thumbprint of the cert without spaces)
TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
What do I need to do differently to get this working?
You need to use MMC to install your certificate in the certificate store and then use the SQL Server Configuration Manager to link the certificate to your SQL Server service. See https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi
Then, make sure that the service-account running you SQL Server service has full permission on the certificate. In MMC, right-click on the certificate, select Manage private key, and then grant full access to the service-account running you SQL Server.
You should restart your SQL Server for the changes to take effect.
Before anything else, you must install the certificate in the Windows certificate truststore.
Did you do that?
The error
You should verify that the certificate
is correctly installed
seems to indicate you did not do this.
I was expecting that the hostname verification would be configurable but from here SSL in MS-SQL2008 r2 it seems as an absolute requirement.
To be honest I am not sure if the trick you did with the DNS entry will work.
It seems that some tweeking works for cluster installations ssl for cluster installations
In your case, may be you should have bought the certificate using the IP as subject name and use DNS to resolve to the FQDN you say.
But of course this implies use of a static IP and most likely it would not be feasible as well anyway.....