I got a few e-mails yesterday warning me that some of my WHM self-assigned SSL certificates are going to expire. I did not setup the WHM originally, but according to their documentation self-assigned certificates are usually created during the WHM installation.
Services that need a new certificate:
cPanel/WHM/Webmail Service
Exim (SMTP) Server
Dovecot Mail Server
FTP Server
All on the same domain (which is our main domain that we use to access whm).
All current services have self-assigned certificates. I don't know the point of having a self-assigned certificates if they create browser errors anyway.
So I guess I have 2 questions:
Are there any issues that could arise from resetting the current certificates?
Do I have to have a certificate at all? Our main domain (that has all these certificates) doesn't use SSL.
I'm afraid I don't have experience of WHM, but I do have experience with ssl certificates, so hopefully this will be helpful anyway.
If there are any existing clients who have been using the services over SSL, they will have already been accepting the existing self-signed certificates, so they should be able to accept the new ones. Whether this will happen automatically probably depends on the client.
You say your main domain doesn't use ssl. However, are you just talking about a website? Are there, for example, email clients which are talking to your Exim server using secure SMTP or to dovecot using secure IMAP for example? If so, then they'd need the server to provide an ssl certificate (and they may need to accept the new self-signed certificate).
Self-signed certificates will cause browser security exceptions that need to be accepted by users and they don't provide a guarantee of identity in the same way that 'proper' certificates do, but at least they enable encryption to be used for communication.
Related
I am developing an app to run in Cloud Foundry.
The app makes constant connections to a web service using https protocol.
The web service uses a pair of self-signed certificate created by openssl.
As there is no DNS setup, I am using IP address as the Common Name(CN) in the ssl certificate.
However, the web service IP address varies from time to time. The ssl certificate has to be re-generated each time.
In order for the app to connect, it needs to trust the SSL certificate so I have been packaging the public key for the web service’s SSL cert as a file with my app.
The problem is that I have to re-upload the app to Cloud Foundry once the public key of the SSL cert changes.
Here are some possible solutions:
Register a host name in DNS. In that case, the certificate is only bound to host name. (Might not be possible cos of the budget. )
Create a private CA and issue certificates from the CA, then install the CA as the trusted CA on the client. It is feasible and a common way for internal services. However, what if the app is pushed to the CF? How can we configure the node for the certs?
Disable the SSL server authentication. Not sure whether it would put the app at risk if the authentication is skipped. For the time being, the app pulls data from the web service.
I've been thinking of keeping the public key in the database. In that case, I don't need to re-upload the app to make it take effect. But I am not sure whether it is a safe way.
Question
I am seeking for a common and safe way to keep the SSL server cert in a Cloud Foundry env. Are any of the above solutions viable? If not, is there any other CF preferred ways?
Thank you
This is a bit old, but in case this helps...
Did you try to generate your server SSL certificate with whatever hostname (even "localhost"). As you are uploading this certificate in your application (i.e. to "blindly" trust it), I think that it could work and this would avoid dependencies with your IP address.
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'd like to run some encrypted connections between some of my own servers. One can use Curl (or some other mechanism) to connect using HTTPS without SSL certificate verification. I'm using PHP, but the language probably isn't significant for this question.
I'm assuming using HTTPS without a SSL certificate is atleast more secure than doing the exact same connection over plain HTTP, since atleast it's encrypted and an evildoer would have to make a much larger effort to intercept en decrypt the information.
As far as I know an SSL certificate only says "this trusted third party says the server you connect to is owned by the guys that claim to own it". If I connect using my own domainname or IP address, I know I'm the owner. What additional value does an SSL certificate provide if I'm the owner of both ends of a connection?
Not verifying the identity of the server you connect to leaves the connection open to potential MITM attacks. SSL/TLS can be used without certificates (with anonymous cipher suites), but they're insecure (and disabled by default); as the TLS RFC says: "Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated."
In addition, the HTTPS specification itself expects there to be an X.509 certificate.
Checking the identity of the remote party is a necessary element for securing your system. It's not very useful to exchange data secretly with a remote party who may not be who they claim they are (even if the secrecy is guaranteed).
This being said, you don't have to go via a commercial CA. You can either use self-signed certificates, which you would have to import individually into each client as trusted certificate, or create your own institutional CA. There are tools to do this, ranging from OpenSSL's CA.pl (see man-page), TinyCA or OpenCA amongst others. Some operating systems also provide their own small CA capabilities.
If I connect using my own domainname or IP address, I know I'm the
owner. What additional value does an SSL certificate provide if I'm
the owner of both ends of a connection?
The certificate assures you that you're indeed connecting to your machine and that the traffic hasn't been intercepted. That's why you need to check that it's a certificate that you recognise.
SSL certificates are more for the piece of mind of your customers or those using your site. In either case, the data is being transmitted over the same connections - it's just a matter of whether or not a third party is certifying you as being safe.
At my last job, we did all of our internal data transfers at my last job via https/ftps but did not have an SSL certificate until very recently. Since the data transfers were internal, it made no difference.
I run an nginx-powered application and I recently turned my attention to using it over https. This is the module in nginx that does this: http://wiki.nginx.org/HttpSslModule
However, I'm somewhat unclear about what is actually required to run a site over https.
What else is there to do to serve my site over ssl? What is the role of the certificate, and is it a requirement that I purchase it from somewhere?
You need a certificate to prove to your user that the server they're connected to is indeed the one intended (and not a MITM attacker).
If your server is to be used by a limited number of users to whom you could give a certificate explicitly, you could use a self-signed certificate or create your own certification authority (CA).
Otherwise, if you want your certificate to be recognised by most browsers, you'll need to get one from a commercial CA.
You should find more details in this answer. You may also be interested in this.
I have a WCF Server Deployed through IIS. I want to Create a Certificate for it. I could do this by making the server a certificate server.
But then when the client connects to that server I want the client to automatically trust the certificate without having to register that the server as a "trusted authority".
Is this possible?
All this seems a lot of work to put username password protection on a WCF Service!
The short answer is no the client will need to add the server cert root as a trusted authority.
The slightly longer answer is that there is a workaround for needing to implement transport security in WCF when using message based authentication - this workaround is usually used when you want to rely upon another security mechanism that the WCF server is not aware of, like an ISA server providing SSL.
Have a look at Yaron Naveh's post. The essential idea is that you create a transport binding that pretends that it is secure.
With all that, you still need security (you don't want to send your creds in the clear) and so will still need a trust chain for your cert. So, it may not actually help you, but hopefully it gives you some options to consider.
Edit
Sorry if my answer was misleading. The server certificate root cert must by in the client trusted store. My additional detail was giving another option for providing the security (you can use an ISA server with a trusted cert to give your SSL connection)
In a similar situation to yours (needing secure communication when pushing client applicaitons to non technical customers) I have programatically installed the needed root certs.
Here is an SO post that details how to do that: How can I install a certificate into the local machine store programmatically using c#?
You can if you add this to your code but be aware of what you are doing!
System.Net.ServicePointManager.ServerCertificateValidationCallback += ( se, cert, chain, sslerror ) => { return true; };
Well if there would be such a way, it would be a security hole.
If a certificate is not linked to a trusted authority it is easily forged. So your choice is either to link it one way or another (directly or through a parent certificate you control), or configure your client so that it does not require the certificate i.e. using http rather than https.
Just keep in mind that it leaves your clients open to a variety of attacks
Edit
One of the possible attack scenarios is a man in the middle attack - a program inserts itself between your service and the client and channels the information though itself. This way the intruder has complete control over the information flow.
It can make copies of passwords or it can "adjust" the results in both directions any way it wants. The only thing which prevents this from happening is the certificates. But if they are not rooted, they can be forged.