I just started working for a new company. They are an engineering company focused mostly on hardware. They don't have a lot of experience with big data dev/test environments. The company has extensive IT security policies. One of them is "absolutely no wildcard certificates". I have worked in other software shops where wildcard certificates were commonly used in dev and test environments. The advantage is that you can spin up servers and use the wildcard certificate without waiting for the accounting department to issue a purchase order to the CA. I believe I understand all of the security issues for wildcards,
If one subdomain is compromised, all subdomains are compromised.
If you revoke the certificate, all subdomains are revoked.
Wildcards may not be compatible on "really old" browsers and servers.
Single private key floating around on several servers pose security risks.
Some CA's void their warranties for Wildcard certificates.
I probably would not use wildcards for production servers -- mostly because of #4. However, I cannot see the above security issues a problem for a dev and test environment. The dev and test servers have internet facing ports. They all have the usual password and multifactor security built-in. Only necessary ports are exposed and all are https. The data is all test and all of the servers are in their own domain with no connection to the companies internal domains.
Does anyone see any potential security problems or other things I might be missing?
I started out thinking that wildcard X.509 certificates was the way to go with moderate to large server/instance development environments. However, the suggestions of AlexP were quite helpful and I believe it is a better way of approaching the distribution and management of multiple environments and X.509 certificates. Here is a description of his suggestions.
You have several environments that you will have to support. Each environment has several servers or instances. Each server/instance requires their own
X.509 certificates.
DEV1, DEV2, ... Development environment
TEST1, TEST2,... Test environment
STG1, STG2,... Production staging and test
PROD1, PROD2,... Production Live environment
The recommended way would be to build a private SSL Certificate Authority (CA). The private CA would issue X.509 certificates for DEV, TEST, and STG. Any development or test machine browser would be manually loaded with the root certificate of your private CA. This way the browser will not squawk about certificate security problems. Each server or instance would have it own unique certificate. Each environment could conceivably have several servers or instances so you could easily have many 10's of certificates to deploy and manage. The use of sub-domain or Fully Qualified Domain Name(fqdn) is also helpful -- DEV1.admin.mydomain.com, DEV1.rest.mydomain.com, TEST1.admin.mydomain.com,...etc. You will need to use the fqdn for the common name of each certificate -- STG1.mongodb.mydomain.com for example. For the production environment, you would use a commercial CA such as Comodo, Symantec, or others. The fqdn for this environment would be mydomain.com, rest.mydomain.com, etc. Private CA certificates are free, easy to create and fast to deploy. Commercial certificates can be expensive and take more time to create and deploy but are necessary. Private CA's represents a good cost, security, and ease of certificate management trade-off in a moderate to large development environment.
Related
I would like to use google certificate transparency API to check the malicious SSL certificates(if any) of my domain. I am able to get all the certificates but how do i check whether the certificate is legitimate or not.
I had found this repository(https://github.com/ProtonMail/ct-monitor) but this simply searches certificates and stores it . What is the use of storing these certificates unless we validate the certificates first.
Can any one suggest me how do i get to know the malicious SSL certificates using this google certificate transparency api.
Certificate Transparency logs are, as explained on the CT site:
simple network services that maintain cryptographically assured,
publicly auditable, append-only records of certificates. Anyone can
submit certificates to a log, although certificate authorities will
likely be the foremost submitters.
The logging of the certificates in this fashion allows for interested parties (e.g. domain owners) to monitor these logs for malicious/erroneous
entries.
But a certificate being logged in a CT log doesn't mean it isn't a bad certificate. As explained on the CT site:
Certificate Transparency relies on existing mitigation mechanisms to
address harmful certificates and CAs--for example, certificate
revocation--the shortened detection time will speed up the overall
mitigation process when harmful certificates or CAs are discovered.
So CT API won't help you in working out whether a certificate is malicious - you need to check using other methods such as checking of certificate revocation lists (CRLs) or by using the Online Certificate Status Protocol (OCSP). See this related question on how to check certs. There are sites that allow for checking of certificates e.g. revocationcheck.com. Modern browsers seem to be converging on the use of compressed lists of CRLs - Mozilla's now using CRLite, whilst Chrome uses CRLSets.
The CT API allows you verify that a certificate has been logged in the CT logs which means that domain owners can monitor them and promptly insert any malicious/erroneous certificates into the relevant CRLs so they won't be used any longer.
I'm going down the path of figuring out the details of securing our SF Clusters. I'm finding that the docs note in a number of places not to use self-signed certs for production workloads. But nowhere does it explain why.
Can anyone from the SF team explain why a self-signed X509 cert is not as secure as one issued from a known CA? I thought the only true difference is that self-signed certs do not chain to a certified root authority, which would mean any clients might not see the cert as valid. But with node-to-node security why would this matter?
So what risk am I taking if I use self-sign certs for node-to-node or even client-to-node security of my production SF Clusters?
For client to node: As anyone can spoof your self signed certificate,
you won't be able to assert from the client you're actually talking
to the correct server. Also, there's no way to revoke a self signed
cert. Finally, end users will see that nasty security warning in the
address bar.
For node to node: same thing applies, but since it's in a vnet behind the load balancer, the
risk of tampering is lower.
Encryption of the data itself will work using either type of certificate, but a MITM attack is made easier.
I am working with a client who needs SSL on their Email and Web Site.
We have their site hosted on a Rackspace Cloud Site (Wordpress so Apache and all that jazz).
From what I can tell their Email is on an ISS server of their own.
They want to apply this SSL Cert they bought through GoDaddy and apply it to this email server and to the site on our hosting server. Now I am only a Web Developer with enough server knowledge to get sites launched and running, But I don't think you can apply the same SSL Cert on two different types of servers.
What would the solution be for this?
Would you purchase a second ssl? Is that even possible?
Sorry if this is a all completely wrong I am trying to use my limited knowledge of SSL to describe the situation.
I'm pretty sure you can use the same certificate if it's going on two servers as long as they are both using the same domain. You don't need to purchase a second ssl. The tricky part might be if the two servers require different certificate file formats.
Also, just do the CSR part on ONE of the servers (use the one you trust the most). On the other server just install the certificate bypassing the CSR part.
My iOS app is in development right now and the services we connect to are using a cert that is signed by our internal (company) CA. My app in many places calls secure web services using synchronous requests. It would be a large effort to switch to async and handle the cert challenge to manually accept certs from our domain.
What I would like to do is to add our CA root cert to our team's provisioning profile so that it is recognized, just in development, as a trusted CA. Can someone help me do this please?
If this is not possible, does anyone have any suggestions? Here are the options I see from best to worst.
Add internal CA root cert to trusted CAs in dev provisioning profile
Buy a cert (don't want to do this because our deployment server already has a valid cert, and i wont want to waste money on a cert that I just need in our dev/test environments).
Switch to ASI framework to bypass challenges (don't want to do this because it makes my app less secure. My code is correct and secure as is, but I cannot test in dev/test. I don't want to make my app worse just so that I can test in my dev env.)
Switch to async requests and handle challenges by accepting all certs from my domain (also don't want to make code changes for working code. Also it is a huge effort for us to switch to async, and we don't have the time).
All help is appreciated! Thanks.
Well I decided to go with 2 and just turn SSL off for our internal machines. Not the ideal solution, but I couldn't find a better one.
We are doing a project in Scala, using Lift to provide some REST style web services for clients (Java-script through AJAX). For some business reasons we decided to put it all under SSL but I'm am not sure where to start. Insights would be much appreciated.
Whatever server software is currently handling HTTP traffic (e.g. Jetty, Nginx, Apache...) almost certainly has some means of adding SSL support and disabling plain HTTP; try that first.
As for the basic mechanism of adding SSL support, it goes something like this:
Generate an RSA keypair (the key size should be at least 1024 bits). This step should prompt you to fill in some information about you, your organization, and the server's hostname ("common name" in X.509 parlance). It should also prompt you for a passphrase, which will be used to encrypt the private key.
The keypair consists of a private key (this is the part you shouldn't share with anyone) and a self-signed certificate, which contains, along with other metadata, the public key.
If you want to get a real cartel-signed SSL certificate, so that members of the general public won't see nasty warnings when they visit your site, you'll need to generate a Certificate Signing Request (CSR) from your keypair and submit that to an SSL certificate authority, who will create a certificate derived from your CSR, but signed with their private key. Luckily, in recent years, the SSL CA business has gotten extremely competitive, so pricing shouldn't be a major hurdle anymore.
If you're not planning to get a real cartel-signed SSL certificate, you can use the private key and self-signed cert as-is.
Either way, you need to tell your web server how to find the certificate (whether self-signed or CA-signed) and private key. Apache HTTPD prefers to keep the two things in separate files; most JVM servers prefer that they be encapsulated in a keystore. The best keystore format for general use is called PKCS#12, it's an industry standard. Making a PKCS#12 file out of a separate key and cert is a bit tricky, look on ServerFault if you can't figure it out. :)
You usually want to put the private key passphrase in the server's configuration file, so make sure that configuration file (and the file containing the private key) have the most restrictive permissions that will still work.
This depend on which application server you're running.
Jetty: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
Tomcat: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Glassfish v2: http://blogs.oracle.com/enterprisetechtips/entry/using_ssl_with_glassfish_v2
Glassfish v3: http://javadude.wordpress.com/2010/04/06/getting-started-with-glassfish-v3-and-ssl/
You're not sure where to start with which bit? The SSL?
Set up stunnel (or similar) in front of your webapp, and firewall your webapp off so that only stunnel can access it. Then your clients can only access your webapp over SSL, via stunnel.