I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
Related
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
On my staging server I am connecting to self-signed https api backend. And by default requests can't be made, because browser treat backend as danger.
I have to open backend url in browser
https://my-api-backend.elasticbeanstalk.com
my-api-backend.elasticbeanstalk.com:8443 uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is not valid for the name my-api-backend.elasticbeanstalk.com. Error code: SEC_ERROR_UNKNOWN_ISSUER
After manually confirm that is secure it works. It is fine for me to do this, but not for managers etc. Another thing I was thinking about blocking backend access from outside and allow access only from frontend.
Is there any solution to this problem other than buying domain a sign it properly?
If it is a staging environment it should reflect a production environment so you should use a real domain signed correctly.
Certificates are free through AWS ACM or LetsEncrypt.
Why not use a sub domain like staging.domain.com, it would be free as well. Otherwise domains are cheap and it shouldn't be worth the hassle.
I have the following scenario:
A network will be set up on a Windows infrastructure
A website will be put on that network - It is not given a domain name and is not available on the internet. It will be addressed only via an internally recognised IP address.
A piece of software within that network will communicate with the website
(we want to avoid the 'Could not establish trust relationship issue' found with self-signed certificates without reducing security as, I believe, the accepted answer does).
The website will also be viewed on tablets and PCs.
After a few days, the service will be be put on a different network (with different IPs).
It will installed on many PCs/Networks.
I want to secure this via SSL, but it seems tricky following the 2015 update that disallowed IP addresses to have certificates.
This post suggests going via a public IP, but the solution may be completely offline in an area without internet access.
I've spent hours researching, but seem to be missing something.
How should this be done please?
I would setup a DNS server with an app.local domain that gets issued the certificate.
Even if you serve up the intermediate certificates in the TLS handshake (which you should ALWAYS do and not rely on AIA), verifying the chain becomes problematic without Internet access as browsers won't be able to reach the CRL URL (Certificate Revocation List). That is, of course, unless we're talking about your own CA (living in the same network) that issues the site certificate.
If everything you describe runs in a well guarded sandbox then you probably don't need the TLS layer at all, ask yourself WHO is the attacker and WHAT are you protecting.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
I am developing a backend section for a company where they need as much security as possible because they will put sensible information in it.
They asked me to add SSL, which I added(the website is coded in codeigniter) but I don't know if a SSL certificate is really needed.
Having in mind that this website will only be accesible by a set of two different IPs, the two offices they have I don't think getting a certificate would be needed. Am I right?
Edit 24 Feb:
The data has the information of projects, list of clients so it is sensitive.
So I think I will go with a self signed ssl.
Thank you all
There are a few other issues you should keep in mind, in addition to those who have previously answered:
Will the users of this site be connecting and transferring this sensitive information over a wireless connection at any point in time? If this is the case, then yes, you need SSL.
HTTPS is not such a burden on server resources as it once was. Especially with a site only being used by a limited number of users at defined locations, you should certainly be able to provide for the maximum number of users.
If this is a private site, and cost is an issue, go with a self-signed certificate. The OpenSSL toolkit is your best bet for this. Numerous guides for setting up self-signed certificates with OpenSSL are available.
Are there legal issues involved with this sensitive data? If you are transmitting customer information in a client database with phone numbers, postal addresses, email addresses, login information - or even more seriously, credit card numbers - then you need SSL. Ask yourself if you would trust a company who transmitted this same information of yours without SSL.
If the client asked for it and is paying for it, this isn't an undue burden on you as a developer, and as a developer you really never want to be in the position where you're arguing for less security. If there's a problem later, it comes back to bite you. Cover your rear end.
Combine this with IP restricted access. If you can, do that at the Apache configuration level. If not, then do it with a .htaccess. Why at the Apache level? Again, that covers your rear end in case you forget to put the restrictions in a .htaccess, or in case someone else comes in and removes them by accident.
If there's even a question about it, use SSL.
SSL certificate is needed because somebody could read the request content on the way to your server. You can't add https to the web page without certificate (check if you have https protocol in the browser page address).
In developing stage you can generate SSL certificate by yourself (use openssl) there is no need to buy valid one. There will be warning in the browser that the certificate is not signed by any authority, but I don't think that is big problem.
If you need to protect clinet-server communication (http request/response headers and data) from being overheard, then you need to install SSL on your sever, and use https protocol. This is useful when you want to hide i.e. user credentials.
If it is just about allow/disable access for mentioned ip addresses, than it is enough to limit it in http server configuration (usually .htaccess).
Please keep in mind, that https requests requires more server/client resources (CPU), so it should not be used if not necessary.