I am using the EC2 Load Balancer to handle HTTPS requests. For Chrome & Safari, having the Load Balancer Protocol set HTTPs at Port 443 with the the SSL cert handles most traffic correctly. HTTPS requests from Safari & Chrome are fine. However in Firefox, I get the connection is insecure "(Error code: sec_error_unknown_issuer)." In checking with a cert checker, I get
The certificate is not signed by a trusted authority (checking against
Mozilla's root store). If you bought the certificate from a trusted
authority, you probably just need to install one or more Intermediate
certificates.
In talking with my cert provider, the information I got was :
As we can see certificate has been installed improperly at the server.
There is no CA bundle at the server that is why browsers may show
warning messages.
How do you install a CA Bundle using the Load Balancer?
The solution is to add the ca_bundle to your load_balancer under "Certificate Chain"
That depends on how you are creating the ELB (Elastic Load Balancer).
If you are creating it from the AWS Console, then, when you create the ELB you can create a new SSL sercificate and, when promted, and as #Emile said, you have to specify the contents of the provided "CA Bundle" under the "Certificate Chain" field.
If you are creating it from the command line or using the API, then when you create the SSL certificate you have to specify the "CA Bundle" contents in the "Certificate Chain" parameter.
Right now, what you probably have to do is to create a new ELB specifying the right paramenters, modify your DNS accordingly and once the change has been applied, delete the old load balancer.
First you'll need to obtain a copy of the appropriate certificate bundle from your certificate authority.
Then you'll need to update the SSL certificate on your AWS ELB. Select "Upload a new SSL Certificate" from the ELB Select Certificate window. Paste your current private and public certificate keys into the appropriate fields and then paste the certificate bundle into the "Certificate Chain" field.
Related
I was able to achieve ssl offloading with Haproxy. So great product and appreciate that capability!
With that said, I need to doing mutual TLS but am a little confused on how that will work with the ingress controller configmap.
Going through this reference i've created a client cert, intermediate cert and root cert.
To note, I am terminating the ssl cert (which is from letsencrpt) on the load balancer currently.
However, the client cert and org CA are different than the lesencrypt tls/ssl cert that I have assigned as the SSL now; does that matter?
So, the first question I would have is does the ssl-certificate have to be set to the CA that will sign the client and server certs or can I just use the new ones I created in the instruction.
Setting up the configmap.
This is the part i'm confused on.
You can setup server-ca and server-crt but I don't think that applys here because after the ssl offloading there is nothing meant to be checked. However, I do want mTLS via the ssl termination.
So there is an configuration client-ca
Sets the client certificate authority enabling HAProxy to check clients certificate (TLS authentication), thus enabling client mTLS.
NB, ssl-offloading should be enabled for TLS authentication to work.
The client in this case being the actual client I want which is the device/frontend. Not the loadbalancer acting as a client to the backend server.
When I look at how this is setup:
frontend mysite
bind 192.168.56.20:80
bind 192.168.56.20:443 ssl crt /etc/haproxy/certs/ssl.crt verify required ca-file /etc/haproxy/certs/intermediate-ca.crt ca-verify-file /etc/haproxy/certs/root-ca.crt
http-request redirect scheme https unless { ssl_fc }
default_backend apiservers
Is it possible to do the same with the controller configmap as what is listed here below? There's a lot more going on that what I am seeing as flags / configurations that are in this methodology of applying client mTLS. Is there a way to achieve this in kubernetes without configmap?
The ssl parameter enables SSL termination for this listener. The crt parameter identifies the location of the PEM-formatted SSL certificate. This certificate should contain both the public certificate and private key.
You can restrict who can access your application by giving trusted clients a certificate that they must present when connecting. HAProxy will check for this if you add a verify required parameter to the bind line, as shown:
the ssl argument enables HTTPS
the crt argument specifies the server SSL certificate, which you will typically obtain from a certificate provider like Let’s Encrypt
the verify required argument requires clients to send a client certificate
the ca-file argument specifies the intermediate certificate with which we will verify that the client’s certificate has been signed with our organization’s CA
the ca-verify-file argument (introduced in HAProxy 2.2) includes the root CA certificate, allowing HAProxy to send a shorter list of CAs to the client in the SERVER HELLO message that will be used for verification, but keeping upper level CAs, such as the root, out of that list. HAProxy requires the root CA to be set with this argument or else included in the intermediate-ca.crt file (compatibility with older versions of HAProxy).
Also, my reasoning for now wanting to use letsencrypt and rather a private CA is because I can't renew device certificates every 60 - 90 days. That would not be efficient. In this case, and please let me know otherwise, I think it better to use either a real key/cert provider or in development testing utilize the openssl certs like in the HAProxy instruction.
It's odd but you really have to think about what a "client" is with these abstractions because I would never use this for a normal web page login but rather the server to server communication and in that sense this server is a client to this server. Or in my case this device is a client to this loadbalancer.
Problem Background:
As part of the Computer Networking course assignment, I have been given task of implementing a Proxy Server ( using python socket and ssl module ) that handles https communications between the browser and the origin server (The real server that my browser wants to talk to).
What I have done so far:
I have implemented the above requirement using ssl sockets and also generated self-signed 'cert.pem' 'key.pem' files.
What I need to do:
Now I just need to tell my browser (chrome 89 on kubuntu 20.04) to accept this self-signed certificate and then test the working of my proxy server.
Reading from this stackoverflow question, I can see that I have to:
(1) become my own CA (2) then sign my SSL certificate as a CA. (3) Then import the CA certificate (not the SSL certificate, which goes onto my server) into Chrome.
My confusion/question:
So if I do this, when eventually I am done with this assignment, how do I reverse all these steps to get my browser in the previous state before I had made all these changes. Also, how to reverse the "become your own CA" and also delete the SSL certificates signed by my CA.
Basically, I want my system to return to the previous state it was before I would have made all these changes.
UPDATE:
I have done the previously outlined steps but now I get an error.
Here is a snippet of my code:
serv_socket = socket(AF_INET, SOCK_STREAM)
serv_socket.bind(('', serv_port))
serv_socket.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context = context.load_cert_chain('cert.pem', 'key.pem')
context.set_ciphers('EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH')
serv_socket.listen(10)
socket_to_browser, addr = serv_socket.accept()
conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True)
At the last line conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True) an exception is thrown: [SSL: HTTPS_PROXY_REQUEST] https proxy request (_ssl.c:1123)
What am I doing wrong ?
As glamorous as "becoming your own CA" sounds, with openssl it basically comes down to creating a self-signed certificate, and then creating a directory where some CA-specific configuration will be stored (I don't fully remember the specifics, but I think it was just some files related to CNs and serial numbers) so basically reversing the "become your own CA" step is something as mundane as deleting this directory along with the private key and self-signed certificate you were using for the CA. That's it, the CA is no more.
And for chrome returning to the previous state, you would just go the the CA list where you added the CA certificate, select it and delete it. Chrome will stop accepting certificates signed by your CA.
Regarding your new problem... In my opinion, you have developed some kind of reverse proxy (meaning that you expect normal HTTPS requests that you then redirect to the real server) but you have configured Chrome to use it as a forward proxy. In this case, Chrome does not send it a normal HTTPS request, it sends a special non-encrypted CONNECT command and only after receiving the non-encrypted response, it negotiates the TLS connection. That's why openssl says "https proxy request" because it has detected a "https proxy request" (a CONNECT command) instead of the normal TLS negotiation.
You can take a look at How can a Python proxy server (using SSL socket) pretend to be an HTTPS server and specify my own keys to get decrypted data?
It's python, but I think that you'll get the idea
Configure Apache and F5 loadbalancer.
From Apache layer we generate CSR and get the trusted cer as:
1) .cer
2) .p7b
Then I convert the .cer and .p7b file to .crt file and configure in our apache as keyfile, certificate and chain.
We are facing some issue while configuring the SSL between F5 and Apache. Our flow is:
Client(SSL) -> F5 (SSL drops ) -> (recreate ssl to apache layer) -> Apache webserver.
1) create CSR from apache web layer, get sign as trusted from the company (not external)
2) configure in ssl.conf and ciphersuite
Now initiate a request using openssl it is throwing:
depth = 1
DC = net
DC = racb
CN = XXXXXX
CA 1 verify error:num=20:unable to get local issuer certificate read from 0x1b9c8d0 [0x1ca04f3] (5 bytes => 5 (0x5))
In order to verify it I modified the /etc/hosts entry as xxx.xxx.xxx.net as 127.0.0.1 and move the chain certificate to /etc/pki/ca-trust/source/anchor and update-ca-trust extract and run the openssl which is return with error code=0 and waiting in SSL session.
What mistake we are doing in F5 no idea.
Can someone throw the lights?
If you're setting up a bridging config, you need both an SSL Client Profile (typically you take your Apache key/cert/chain) and an SSL Server Profile, and both are chosen on the Virtual Server configuration.
For the Client Profile you first need to import the private key, the certificate(s) and of course you have to see on the Certificates screen that the private key matches the certificate.
Usually for the Server Profile, if we know that we can trust the backend server, instead of setting up something with certificates of your own, we just choose the unsecure-compatible profile and it will work in almost all cases.
If there is no need to setup SNI, it's enough to make it work.
I'm trying to have https for a website which is hosted in AWS EC2. I have followed the steps mention in the following link.
https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04
But still its showing the privacy thing to all user who are visiting the website. How can make the certificate as trusted or how long it will take Amazon to make it a trusted one.
Please help me to solve this. I'm stuck with this for last 2 days. Answers will be appreciated and Thank you.
You can use AWS Certificate Manager to issue free SSL certificate signed by AWS Certificate Authority. However for this to work, you need to use a Load Balancer and attach the certificate to the Load Balancer which will forward the traffic to the EC2 instance.
Depending on your requirements you may wish to use SSL termination on an Elastic Load Balancer (ELB) instead.
This involves creating a free AWS certificate and an ELB. Attach both your instance the certificate to the ELB with HTTPS forwarded to port 80 on your instance.
Then just point your DNS name to the ELB. If you're using Route53 then you can just use an A-record alias.
Edit: If you want to automatically direct HTTP to HTTPS you'll need to check the X-Forwarded-Proto header in Apache's .htaccess file. More information here.
The certificate which you are using is a "Self Signed Certificate (https://en.wikipedia.org/wiki/Self-signed_certificate)".
In order to get rid of insecure certificate or privacy issues on HTTPS, you need to get your CSR signed from a trusted CA like Comodo, Godaddy etc.
Ref -
https://in.godaddy.com/help/apache-generate-csr-certificate-signing-request-5269
https://help.comodo.com/topic-437-1-843-10843-.html
OR
In case you want free verified SSL certificates, "letsencrypt" is the way to go.
https://letsencrypt.org/
You don't need to pay anyone for a certificate. Just use LetsEncrypt and their CertBot ACME client. The CertBot automates the task of issuing and renewing certificates.
LetsEncrypt is the leading free SSL certificate authority (CA) and their certs are as good as any paid cert.
I have purchased an SSL certificate and installed it to my Heroku app.
However when I try to access my site via https, Chrome reports that:
The identity of this website has not been verified. • Server's
certificate does not match the URL.
Other browsers report a similar message.
Inspecting the certificate information in Chrome shows that my site is still using Heroku's certificate, issued by Digicert (instead of my own CA).
Any ideas as to what I could be missing?
The problem had to do with an incorrectly set DNS record.
As per the documentation (...), once the certificates are uploaded to Heroku, do:
heroku certs
This provides you the correct end point for the SSL enabled domain. This is a domain that looks like "tokyo-2121.herokussl.com".
Next, go to your DNS service provider and update/add the CNAMe record for the SSL enabled domain to point to "tokyo-2121.herokussl.com".