We're currently with a webhost that has an SSL cert for us. Unfortuantely (unrelated to our webhost), we are required to move to a new host. While we setup the new host, with new temporary subdomains while we look to move, if we buy a new cert and install it on our new machines, will it "invalidate" the older one (if they cover the same domains)?
ie old webhost has cert for www.oursite.com and oursite.com. New webhost cert will cover new.oursite.com, oursite.com and www.oursite.com. If there's no DNS change until we're ready to move to the new site, will our old cert be affected?
Can multiple SSL certs be valid?
yes
will our old cert be affected
no
There is no relation between the two certificates. The browser validates the chain from the site's certificate through the CAs until it reaches a trusted (built-in) root CA.
You can either reuse the existing certificate or get a new one, if your new provider enforces it.
Multiple SSL certificates is valid for the same domain. You want to move to new host and your new host provider's giving ssl certificate with host then you should continue with new host provider certificate in place of old one. Don't pay double for ssl certificate.
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.
Can I use a certificate from letsencrypt to sign local certificates?
I'm annoyed when accessing routers and APs at 192.168.x.x to get security warnings.
I could create my own root cert, and import it into all my browsers etc, and create certs for all the local servers.
But I'd rather have the chain device -> www.example.com -> letsencrypt -> root
Then also guests could use my local servers/services without this security error.
No, you can not because the certificate issued to you by letsencrypt will not have the keyusage certificate signing enabled. Without this attribute in the issuer, any browser or SSL client musth reject the certificate.
If this were possible, anyone could issue valid certificates for any server simply by having a valid certificate from a trusted CA
If you want to issue certificates for your local servers you will need to create your own CA and include the root certificate in the truststore of each client
Yes, you can... but not like that
Yes, you can get certificates for servers on a private network. The domain must be a real domain with public txt records, but the A, AAAA, and CNAME records can be private/non-routable (or in a private zone).
No, the way to do that isn't by using Let's Encrypt certificates to sign local certificates.
You can accomplish exactly what you want to accomplish using the DNS-01 challenge (setting txt records for your domain).
Who is your domain / dns provider?
Immediate, but Temporary Solution
If you want to test it out real quick, try https://greenlock.domains and choose DNS instead of HTTP for the "how do you want to do this" step.
Automatable Integration
If you want a configurable, automatable, deployable solution try greenlock.js (there are node plugins for Cloudflare, Route 53, Digital Ocean, and a few other DNS providers).
Both use Let's Encrypt under the hood. Certbot can also be used for either case and can use python plugins.
Possibly related...
P.S. You might also be interested in a service like Telebit, localtunnel, or ngrok.
I have my website https://www.MyWebSite.com running on port 433. But I also have a admin login that only are available from the office local network http://MyServer:9999/Login.aspx. Both addresses points to the same site but different bindings.
Is it possible to get the one on port 9999 to use https? I tried creating a self signed certificate in IIS but my browser still complained, even though I exported the certificate and stored it in my CA Trusted root.
So just to sum everything:
My regular site: https://MyWebSite.com <-- working fine
My admin login, only accessible via local network: http://MyServer:9999/Login.aspx works fine.
When adding a selfsigned certificate issued to "MyServer" (not MyWebSite) and add the new binding on port 9999 I though to the website but Chrome is giving me a warning NET::ERR_CERT_COMMON_NAME_INVALID, even though the cert is Issued To MyServer and are trusted
Is it possible to get the one on port 9999 to use https?
yes it is possible to setup another port with selfsigned
certificate.
Normally Selfsigned certificate will have fully qualified machine name
e.g. machinename.subdomain.domain so you have to browse using https://machinename.subdomain.domain:9999/
Please double check what error you are running into ,In chrome
Your connection is not private
Attackers might be trying to steal your information from in08706523d (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
in IE,you may get
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
In that case,assuming you have given hostname as * in IIS binding, and also installed the selfsigned certificate installed your "Root Certification Authorities " You should be able to browse to
https://machinename.subdomain.domain:9999/ without any issues
I am going to use an SSL certificate on my chat application based on XMPP(ejabberd) which is hosted on an IP.
So, I will be using the IP as the common name when I am generating my SSL certificate. But the server that has everything hosted on it, refers to the IP using a hostname as abcd.yourserver.net.
Therefore, I am confused as to if I have to use the IP or this weird hostname while generating my SSL certificate and if in future I decide to use a domain name instead of the IP for my application, will I have to buy a new SSl certificate or can I regenerate the old one. Also, can I change the type like wilcard or single certificate?
P.S. I have never bought an SSL certificate, so forgive me if the question is newbish.
When generating an SSL certificate for an XMPP server, you have to use the domain name of your XMPP service.
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.