I've applied my PKCS12 certificate to my gateway.
My certificate is a wildcard certificate and i'm trying to apply it
to the gateway so I don't have do this for all my micro-services.
These are the settings in my properties file for development:
server.port:8443
server.ssl.enabled=true
server.ssl.key-store=integration.domain.net.p12
server.ssl.key-store-password=*********
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=integration.domain.net
The dev server starts up and SSL is enabled. When I open the connection to https://localhost:8080/ I am redirected to :8443 as I expect. However, the browser is indicating the connection is 'Not Secure'.
I can see that my certificate is being used so I'm a bit confused as to why this is not working. I'd like to know how to resolve this so that our clients see that our gateway is properly secured.
Does anybody have any ideas or suggestions?
thanks,
Nevermind. I figured this out. My certificate is obviously looking for a valid domain or subdomain that corresponds to the information contained therein. So of course, localhost is not there. I just added a dev-integration.domain.net to my /etc/hosts file for development and everything is just fine.
Sorry if I wasted anyone's time.
Related
Laravel application deployed on Kubernetes and making requests to https://maps.google.com/maps/api/geocode/json failing with:
SSL routines:tls_process_server_certificate:certificate verify failed
The same application works when running on Docker.
I have appended Google's Root CA certs from here https://developers.google.com/maps/root-ca-faq#what_is_happening to the server's trust store but no luck there either.
I can disable verification but that's not the correct approach.
Any ideas would be much appreciated.
Thanks.
According to the OP, the solution was:
The issue was that our security team scans external certificates and
re-package them with the company's own cert. Once I added the
company's cert to the trust store, everything worked fine. It seems
it's only an internal issue.
I have written a restful API project which is developed using spring boot and I am using the embedded tomcat and running a jar on a linux server.
The APIs are live at:
https://api.arevogroup.com:8089/api/regions
and I can see the verified and correct SSL as well as in the given screenshot.
but I am getting an this exception in the postman when I call these apis.
These APIs are consumed by a Xamrin based app which seems to work all good when consumed using iPhone but gives this same exception when the APIs are accessed via android.
I guess, the way I have generated the ssl certificate has some issues.
I have used a pfx file and my SSL config in properties file looks like this:
###SSL Key Info
security.require-ssl=true
server.ssl.key-store-password=PASSWORD
server.ssl.key-store=classpath:ssl_pfx.pfx
server.ssl.key-store-type=PKCS12
I have 2 questions, if disable the ssl verification, would the communication still be encrypted or not? (man in the middle attack is still possible but the info will still be encrypted, right?).
If not, how can I fix this?
You can't disable the verification of the server certificate. No browser will allow you to do it, except on an exceptional basis (the user must confirm the exception). If the client disables the verification, than the communication will be encrypted (i.e. no passive attack will be possible).
The errors you see are cause by a misconfiguration of your server.
Your certificate chain contains just the certificate for your server and lacks the intermediate certificate CN=Go Daddy Secure Certificate Authority - G2. You need to download it from Go Daddy (it is the one named gdig2.crt.pem) and add it to your keystore.
Refer to this question on how to do it.
Some browsers cache intermediate certificates and are able to verify your site even if one certificate is missing. However you should not rely on it.
security.require-ssl=true
server.ssl.key-store-password=PASSWORD
server.ssl.key-store=keystore.jks
server.ssl.key-store-provider=SUN
server.ssl.key-store-type=JKS
Used the jks file instead of pfx and it worked all good. Thought to share with others too.
After modifying my Caddyfile to try a recommendation on this platform...i still can't get an
HTTPS connection in my browser..Chrome keeps saying
"Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID"
Here's my Caddyfile :
localhost:9000 {
bind {$ADDRESS}
proxy / 197.211.58.62:9000
tls self_signed
}
What am I doing wrong?
The caddy docs says the "self-signed certificate [is stored] in memory (untrusted by browsers, but convenient for local development)".
You'd have to generate the self-signed certificate outside of caddy and add it like a regular certificate.
Here's a guide to do it on Linux and MacOS or Windows
Config Example from the docs
tls ../cert.pem ../key.pem
This snippet assumes the keys are located one folder up
BTW All this should work with Caddy 2
1) http and no-dns (working)
I was using nifi on http, and it was working fine. at that time I was accessing it via ip or server name itself. everything was working fine.
2) https (self signed) and no-dns (working)
i did https setup using toolkit and it worked, although chrome kept showing red color message. which was expected. but atleast things worked.
3) dns (internal) + signed certificate (external authority (Symantec))
dns works fine, as I am able to ping the box using dns. also i added this dns to etc host file.
even though nifi is internal to org, I still went head and bought a certificate. and CNAME i used was the dns name of my server.
certificate i got was a chained certificate
my_dns_>TrustedSecureCertificateAuthority5>USERTrustRSAAddTrustCA>AddTrustExternalCARoot
I create a JKS, and added all of them in it, also added a key_pair to JKS, and I appended all certificated to key_pair too.
Then I changed nifi.properties and used same jks as trust-store and key-store.
now if i use nifi with new dns and https, i am getting "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" (attached image) on Chrome. On IE, i get a TLS error. so I dont think thr is something wrong either with certificate or browser.
if I give url as (see image) https://server_name:9447/nifi, nifi opens up..with but still shows up red color warning, but this time is not for self signed certificate, but for name not matching. which confirms that nifi web server has access to my new jks, and it also reads it...but then why it is not working?
what am i missing here? can nifi run on externally bought certificate? or it always has to work with self-signed certificate?
if you are running nifi with external certified certificate, please share your configuration.
do I still have to use toolkit? or toolkit does same thing, which i did by buying the certificate? if true, what am i missing here?
so here is how i resolved it.
after nothing worked. I went back to https setup of nifi, where nifi generates keystore and truststore jks.
and then i downloaded both, and edited it. I removed all previous certificates (self signed one). and then added my CA certificate chain.
then simply uploaded them back. then just restarted nifi.
nifi is now on https.
Attempting to implement client authentication with an SSL cert, according to this HOWTO,
I receive the following errors.
Apache:
Re-negotiation handshake failed: Not accepted by client!?
Firefox:
ssl_error_handshake_failure_alert
I assume it is a configuration error, but have not been able to locate it.
Additional info:
Commercial CA server cert servers secure works without problem in Apache 2.2 & Passenger.
Only client authentication related directives do not work.
Is your certificate signed by verizon or someone like that? If not, you might want to add an exception in firefox. By default it stops you.
pd. doesn't sound like a passenger question
When you require client certificate authorization, you have to point Apache to file containing the root CA (and intermediates also) certificates which issued the client certificate
Also post your client authentication config part.