When using Oplon's load balancer, is there any way to setup SSL certificates with automatic enrollment and updates? For instance with let's encrypt service or something like that.
YES, you can find documentation in the links below
https://www.oplon.net/en/product/lbl-adc-en/
https://www.oplon.net/en/knowledge-base/acme-sslcertificate-2/
Furthermore, from version 9.9.7 you can use REST commands to manage thousands of certificates and obtain lists of certificates to centrally manage the expiration and renew.
It's never been easier to create and manage SSL digital certificates!
Related
I'm looking to buy SSL certificate for PWA.
The domain is bought from godday, where I checked a couple of options:
https://in.godaddy.com/web-security/ssl-certificate?isc=sshl6in01
https://www.comodo.co.in/ssl-certificates
They have got multiple types of certificates.
Which one is best suited for PWA?
In my case, the app takes the user name and number and saves them in the DB, and it also shows some data from DB to the user.
Service workers, as part of PWAs, do not need special SSL certificates to work. They simply need a working secure connection (HTTPs).
There are many hosting platforms offering already a SSL certificate out of the box. Of course it depends on your requirements and constrains about hosting providers. However if you are free in the choice of the hosting solution, I would suggest to start with a simple solution. This as general advice, also in line with what Paul suggested in his comment.
Firebase hosting is an example (here more details on how to use a custom domain):
I'm trying to apply SSL to my kubernetes clusters (production & staging environment), but for now only on staging. I successfully installed the cert-manager, and since I have a 5 subdomains, I want to use wildcards, so I want to configure it with dns01. The problem is, we us GoDaddy for DNS management, but it's currently not supported (I think) by cert-manager. There is an issue (https://github.com/jetstack/cert-manager/issues/1083) and also a PR to support this, but I was wondering if there is a workaround for this to use godaddy with cert-manager since there is not a lot of activity on this subject? I want to use ACME so I can use let's encrypt for certificates.
I'm fairly new to kubernetes, so if I missed something let me know.
Is it possible to use let's encrypt with other type of issuers than ACME? Is there any other way where I can use GoDaddy DNS & let's encrypt with kubernetes?
For now I don't have any Ingresses but only 2 services that are external faced. One frontend and one API gateway as LoadBalancer services.
Thanks in advance!
yes definitely you can use the cert-manager with k8s and let's encrypt will be also nice to manage the certificate.
ACME have different api URL to register domain. from there also you can get wildcard * SSl for doamin.
in simple term install cert manager and use ingress controller of nginx and you will be done with it. you have to add the TLS cert on define it on the ingress object.
You can refer this tutorial for setup of cert-manager and nginx ingress controller.
https://docs.cert-manager.io/en/venafi/tutorials/quick-start/index.html
If you are looking to connect publicly-trusted CAs to Kubernetes via cert-manager (such as GlobalSign, DigiCert, Entrust), you can use Venafi Cloud as an issuer with cert-manager to automate certificate renewals for Kubernetes.
Venafi Cloud connects to third-party CAs and is integrated with cert-manager. Venafi Cloud also has a built-in certification authority for privately trusted certificates for internal-facing infrastructure such as containers.
Here are the links that are relevant to get this this set up:
https://cert-manager.io/docs/configuration/venafi/#creating-a-venafi-cloud-issuer
https://www.venafi.com/venaficloud
The accepted solution does work -- a different issuer is one way to go. Though if you want to use the ACME issuer, you'll need to solve challenges. This can be done via either a HTTP01 solver or a DNS01 solver. If you choose to go with the DNS01 solver, you'll either need:
to move your DNS hosting from GoDaddy to one of the supported providers.
or you can try using this GoDaddy Webhook provider, which you may already be aware of. Though I can't guarantee that the project is in working status.
I'm having a bit of trouble understanding a bit about SSL, namely self-signed vs certified.
First, is my assumption that a self-signed certificate will still prompt the common browser warning message?
Second, data from a https domain doesn't transfer to a http domain, right? So if I had my site at domain.com, and my api at api.domain.com, I would need two certs, and have both of them setup for https?
Last, I noticed there are free SSL certs at sites like StartSSL. This feels fishy, given it can easily cost $100 for a cert at other sites. Am I wrong in being concerned?
Using a self-signed certificate will cause browser warnings. Your assumption is correct.
It depends; some browsers may warn when this occurs. But you absolutely should serve all of your services on HTTPS, so that clients can authenticate your site(s) and so that the connection is private.
It is possible to support multiple domains on a single certificate, via the Subject Alternative Name (SAN, subjectAltName) X.509 certificate extension. You could also use separate certificates.
StartSSL is trusted by all browsers; their certificates will be accepted and there is nothing "fishy" about them. You could use StartSSL's free offering to obtain two certificates - one for each domain.
If you want a single certificate for multiple domains via the SAN extension, you will have to find a product that supports that, and it will probably not be free. The Let's Encrypt initiative is working to
change the landscape in this regard, but they have not yet launched.
I need to enable SSL on my website.
Q1> What should I do to enable this service?
Q2> Should I change my code (i.e. PHP+JavaScript+MySQL )?
Thank you
Q1> you need to generate a certificate signing request and send it to a trusted certificate authority to be signed, usually for a fee. I use SSL.com regularly because they give me responsive customer support. After they sign the certificate, they will it send back to you or you can download it. Then you install the signed certificate on your server.
If you are running Windows, try http://www.ssltools.com/manager for a tool that generates the csr.
Q2> you can configure it in the server settings, but you can also programmatically implement it in your code. For instance, if you want to open sockets in your code, or if you want SSL on certain pages (although modern servers allow selective SSL implementation in the settings).
I have a distributed application consisting of many components that communicate over TCP (for examle JMS) and HTTP. All components run on internal hardware, with internal IP addresses, and are not accessible to the public.
I want to make the communication secure using SSL. Does it make sense to purchase signed certificates from a well-known certificate authority? Or should I just use self-signed certs?
My understanding of the advantage of trusted certs is that the authority is an entity that can be trusted by the general public - but that is only an issue when the general public needs to be sure that the entity at a particular domain is who they say they are.
Therefore, in my case, where the same organization is responsible for the components at both ends of the communication, and everything in between, a publicly trusted authority would be pointless. In other words, if I generate and sign a certificate for my own server, I know that it's trustworthy. And no one from outside the organization will ever be asked to trust this certificate. That is my reasoning - am I correct, or is there some potential advantage to using certs from a known authority?
There is no need for you to use an external public CA for a closed community project. In many larger organisations they operate an internal PKI to issue certs for internal projects like this. An advantage of using a PKI is that you can setup a trust relationship between the various components based on a single securely distributed root certificate / trust anchor.
However, if the project allowed internal users to connect securely to an internal service via their web browser you may want to consider using a public CA issued cert. The alternative is to make sure that every browser that may need to connect to your service trusted your root cert; this is to prevent browser warning messages.
I'd say it's reasonably safe, unless you think a ninja infiltrator is going to swap your server on you.
The 3rd party is there to make it harder to just 'up & generate' a new cert. Someone could re-create a self-signed cert on a new machine with the same details, it wouldn't be the same cert, you'd have to add an exception for it too, but your users probably wouldn't know the difference.
As long as your system is running inside your group and there are no plans to expand it (and plans do change, so keep that in mind), it is just fine to setup your own simple PKI infrastructure.
If you do end up expanding beyond your organization, all you need to do is distribute your root certificate to the parties you will be communicating. This gives actually a fine grained control to your partners how much trust they want to put in you vs the public CA infrastructure.