I have an api gateway setup. It has a custom domain name setup on a regional endpoint and is using a certificate in ACM. I am able to make successful requests to the custom name from my local machine and even with curl from the remote machine I'm attempting to use. However, from the java application running on the remote machine I see this
! javax.net.ssl.SSLException: hostname in certificate didn't match: <my.custom.domain.name.com> != <*.execute-api.us-east-1.amazonaws.com> OR <*.execute-api.us-east-1.amazonaws.com>
I have a route53 alias record pointing to the target domain name of the custom domain name endpoint configuration.
Any idea how to resolve this without just removing host checking from the java application.
Related
We have a splunk instance which is exposed to internet via say https://splunk.mycompany.com
When we access the above URL browser says connection is secure meaning all certificates are ok.
Now splunk REST API service is running on port 8089. So to access splunk REST API we have to hit
https://splunk.mycompany.com:8089
Whenever we are hitting the above URL we are getting certificate issues and browser is saying "your connection is not private"
Error is: NET::ERR_CERT_AUTHORITY_INVALID
As I am still accessing the same hostname via https (and a new port) it should establish a secure connection. But why it's failing to validate certificate authority?
Edit: I have been told by the splunk team to take ther certificate of https://splunk.mycompany.com and install in the java keystore in the machine from where the REST API call is being made. They also told this is working for otheres. My question why it is even needed?
You should enable SSL on port 8089 via server.conf file.
Have a look at the Splunk Documentation here: https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/ConfigTLSCertsS2S
Using Kong v.2.8.0-alpine docker version, I get SSL errors "no SNI provided by client, serving default SSL certificate" (which is the internally generated KongHQ cert). My host certificates are loaded against the /certificates endpoint with the desired SNI entries (and viewing the certificate from the admin endpoints show my certificates).
Using a springboot application (v2.6.2) or a standalone java rest client, SSL calls are successful through Kong when the server name (https://this.host.com:8443/some-endpoint) is used as the host. However, when making the same call within the Docker network by referencing https://kong:8443/some-endpoint, the call fails with a handshake failure related to SNI being missing. Viewing the java ssl:handshake debug output, the server_name extensions is present on the fqdn host configuration, but is missing when using the docker container name.
The version of Java used is 1.8_0_212 and 1.11.
I am unable to reproduce this issue with Python or curl.
Is there a way to override the Kong default certificates?
I actually have a hosting service who has a subdomain, that subdomain function is to redirect to my local server where I have my services, for example:
My domain: example.com
Subdomain: guaymas.example.com // His function is to redirect to my server (firewall)
Redirect to a port : guaymas.example.com:8080 // where I have my services
And through a port I have a web service, in order to make the data transfer more secure I wanted to implement a SSL certificate but because of my configuration I’ḿ not able to generate the certificate with letś encrypt (because buying one is not an option), I can’t verify with http or dns method, Is there any other method that I can use to generate the SSL certificate?
PD: I'm using GlassFish and Soap web services on JAVA, those are running on Linux Server and my distro is deepin
Thanks a lot
When I run NiFI 1.8 on my local machine (http://localhost:8080/nifi) I am able to interact with the application through the API using Java. I can start and stop processors, and I get a 200 response code everytime.
When I use the same code to interact with a remote NiFI instance (which uses authentication) I get a SocketException, with the message "Unexpected end of file from server"
I tried setting credentials of the HttpURLConnection but it made no difference. Is this an issue with a certificate? If it is I'm not sure how to obtain and set the correct one.
Any clues?
There are multiple ways to authenticate against NiFi. All secure instances can accept client certificates by default, so if you have a user entity configured for some identity nifi_client, you can issue a certificate with that CN and use it when invoking the API from your Java client. Generally this involves putting the key and certificate in a Java Keystore (*.jks) and having a truststore that contains the public certificate of the NiFi server. There are specific instructions for handling certificate authentication in the NiFi Admin Guide, and you can look at the NiFi CLI as an example of an authenticated client.
I know that Kerberos does not work with IP adresses, it relies on domain names and correct DNS entries only.
But I found that old versions of overthere library allows to use IP address with Kerberos authentication.
I extracted code from overthere and created small java project that demonstrates that https://github.com/igolikov/KerberosWithIP
It uses Apache HttpClient to send WSMan request to hyper-v host.
I also found that it works with httpclient 4.3.3 and it doesn't work with httpclient 4.4.1
How it is possible that it works with IP?
UPD1. I suppose that httpclient or something in sun.security may use revers DNS lookup. I tried to intercept traffic with Wireshark, and found 1 Revers DNS lookup (in-addr.arpa), but it responded with "No such host" because default DNS server cannot do revers DNS for this IP.
UPD2. Here is server configuration
There are SPNs for host name and for IP address
SPN( 1 ) = WSMAN/10.10.64.60 1+=1
SPN( 1 ) = HOST/somehost.corp.org.com 1+=1
SPN( 1 ) = HOST/somehost 1+=1
Kerberos can work without DNS just fine, the problem DNS solves is both sides of the connection agreeing on the same service principal to use. If I use the kerberos API to fix that principal to standard one, then as long as the server side has that prinicpal in it's keytab it will continue to work.
I.E. you have to know the kerberos principal that the service you are connecting to uses before you can connnect. Most service principals are of the form
service/dns.name.of.host
But the service principal can be anything as long as the client software knows what to use "somehow".