Question on the SAN list of a certificate please.
Currently, I have a web application where mTLS, mutual TLS, two way SSL is enabled.
All my clients have the valid sets of certificates and they all pass the handshakes and are able to get the response payload when invoking my service over the web. They are all very happy.
However, as the developer, I am not able to get into my own service if mTLS is active, when running on localhost.
Hence, my immediate reaction was to ask my security team to add localhost in the SAN list.
However, they told me this is not secure and considered as bad practice to add localhost.
I tried to look at documentations online, without finding anything concrete, or that I can understand.
I do not want to disable mTLS for my local host testing. I do not want to cheat the process in anyway by deploying some sort of insecure trust.
My questions:
Why adding localhost as entry in the SAN list is considered bad practice and unsafe?
How can I test the app deployed on my localhost then?
Thank you
Why adding localhost as entry in the SAN list is considered bad practice and unsafe?
Publicly issued certificates should contain only domains which are fully controlled by the party owning the certificate. localhost is not owned by a single party and should thus not be part of a certificate issued by a public CA. But it can be part of a self-signed certificate or a certificate issued by a private, i.e. only locally trusted CA, since in this case the scope of the certificate is limited by the scope of the trust into the CA.
How can I test the app deployed on my localhost then?
It is not fully clear what exactly you want to test. But you can make your local machine appear as any domain by adding a mapping to the hosts file. This way you could access it locally by the public domain name instead of only localhost. For details see for example Adding a website to hosts file and testing it. Note that this change only affects DNS lookups on the local machine, but this is probably what you want for testing.
Related
I've been tasked with development of an intranet interface for command line software, and now I'm researching security options. Our command line application is finished, but I haven't started writing the web interface. I don't know exactly what the security requirements are for potential customers, although I believe ssh is generally acceptable for the command line interface. With this in mind, I'm asking for help developing a menu of choices with their associated pros/cons. Some day, we may consider releasing our web interface to the internet, so I'm willing to consider more security than currently necessary if it's easy and/or free.
I've been doing a lot of reading, and my tentative conclusion is that SSL security with no certificate is the best approach, not because less security is unacceptable, but because SSL is the standard and because it doesn't appear to be difficult to set up. I, a security non-expert, wouldn't need to explain why less security is acceptable to security non-experts. I could upgrade my application to use a certificate in the future if necessary.
Here's a list of SSL related security choices, sorted by my perception of security level with my comments. What level of protection do I need?
No SSL. This might be acceptable if our customers aren't worried about their employees seeing/changing each others' data. Their employees might want to share results with each other anyway, and I could use IP based access control and/or passwords for security.
Do SSL with no certificate. This encrypts the communication, which at least protects the data from being read by unauthorized employees. Using a password, this is the same level of security as ssh on the command line, right? I don't need to worry about man-in-the-middle attacks in an intranet, right? A con for this approach would be if there were loads of browser warning messages.
Do SSL with a self-signed certificate. What does this give me that no certificate gives me? If the DNS can be changed inappropriately, then the customer then my application is the least of their concerns. Worded another way, if the DNS can change, then I think ssh would be vulnerable too.
Do SSL with a local Certificate Authority. OpenSSL lets me make my own Certificate Authority. What does this give me that a self-signed certificate does not? I'm assuming that on a LAN, it's less important for the server to be verified.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
For reference, this page might be useful for comparing certificates:
http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts
[update]
Here's an article discussing the risks and rules of obtaining an internal certificate from a public CA.
Yes, certificates are still useful for Intranet SSL.
There's an important difference between SSH and SSL-without-a-certificate: when you first connect to a server with SSH, your SSH stores the server's fingerprint. If you then try to connect to what the SSH client believes to be the same machine but gets back a different fingerprint, it alerts you that there might be someone intercepting your communications.
SSL-without-a-certificate, on the other hand, does not store the server's fingerprint. Your communications will still be encrypted, but if someone somehow hijacks the DNS server as you mentioned, or, as Rushyo notes, does ARP poisoning or something similar, they would be able to perform a man-in-the-middle attack. SSH, as previously mentioned, would (supposing you had connected to the correct server some time in the past) notice that the fingerprint had changed and alert you.
A self-signed certificate would be comparable in security to SSH. A man in the middle could generate their own self-signed certificate, but as long as your applications are configured to only accept that self-signed certificate, you should get an alert similar to that that SSH will give you.
A local certificate authority gives you security similar to self-signed certificates, but may be more scalable. Should you have multiple servers, each can have their own certificate, but a client only needs the top-level one to trust all of them. If a server is compromised, you can revoke its certificate rather than having to change every server's certificate.
I don't believe an external certificate authority has any advantages, other than possibly less configuration if your machines already have the certificate authority trusted.
Lastly, I don't know enough about two-factor authentication to evaluate it, but for most applications, SSL should be sufficient.
Disclaimer: I am not a security expert.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
The benefit is that you don't need to learn how to setup your own Certificate Authority if you need to manage a decent number of certificates and/or machines. Such a certificate would already be trusted by all browsers without you needing to install your own certificates into the trusted store.
However, this is actually less secure because somebody could purchase a certificate for a different intranet and use it on your network. For this reason, SSL vendors no longer offer this service. For more information, see: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935
If you only have a very small intranet, then I would recommend using a self-signed certificate, and then just add each self-signed certificate to each computer's trusted store.
However, it quickly becomes impractical to install a new certificate on every computer in your intranet whenever you want to add a new computer. At this point, you want to setup your own Certificate Authority so that you only need to install a single CA certificate in each computer's trusted store.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
Let's suppose I have a web application that is accessed externally via http://webapp.mydomain.com and internally via http://webapp.intranetservername/
Do I need two SSL certificates? Or can the same SSL certificate be used?
You will need two SSL certificates, and the one for the intranet server will have to be self-signed, because certificate authorities are prohibited from signing certificates for internal domains (as there is no way to verify ownership of such a domain).
It is ordinarily possible to create a single SSL certificate that is valid for multiple domains (by using the Subject Alternate Name extension). However, again, a CA cannot sign one unless they can validate all of the domains it claims to be valid for.
In principle, you can have have a single certificate with two Subject Alternative Names for webapp.mydomain.com and webapp.intranetservername. In practice, that's not realistic, since no CA will issue something to .intranetservername, unless it's also a proper public domain name.
Generally speaking, if .intranetservername isn't a registered domain, no CA will issue a certificate for it, so you will have to use your own CA anyway.
If you can expect both types of clients (internally and externally) to trust your own CA, you could of course issue a certificate with two SANs with this CA.
If you expect different types of users (trusting only the default bundles of CAs or trusting your CA too), you'll have to use two certificates, one issued by each. You may also need to bind them to separate IP addresses (but availability of an extra internal IP address on a LAN isn't necessarily a problem).
More fundamentally, is there any good reason why you're calling the same web application, running on the same machine, by two distinct names, whether you access it internally or externally? Why can't people within the intranet talk to webapp.mydomain.com?
I presume this may be an attempt to increase security somehow, but if it's the same machine, it will be on both networks anyway, so I'm not sure what security improvement this name separation brings.
If you really want separate names, you could have them both on your external domain (e.g. webapp.mydomain.com and intranet.mydomain.com), and have a certificate issued by a well-known CA for both (I'm still not sure about the advantage of separating the names on the same machine, though). Indeed, certificate validation is only based on the name, and you can easily have your DNS servers point intranet.mydomain.com to a private IP address (e.g. 10.1.1.1). People from the outside won't be able to access that address, simply because it won't be routed, but it will work fine within your intranet (provided machines on the intranet are able to make DNS requests, some environments block this).
You will need two, since the SSL certification works on domain name, and you have two domain names there.
You could use the same on both, but there would be an error message displayed in most browsers warning users that the cert was not authentic.
You can get around the cost implication of having to register both with Verisign by self-certifying the intranet site, and distributing the self-cert to all of your employee browsers.
Depending on the size of the enterprise and number of users which will access "webapp.intranetservername" this may or may not be cheaper and easier than simply regging both domains with Verisign.
I am writing an application for a business who have an existing website.
I would like the application to be behind SSL, and on my server - so completely separate from the existing business's website.
So for example, they are: http://www.dogsittingservices.net - pointing to their website, on their host.
I would like to be able to have https://secure.dogsittingservices.net - pointing to the web application sitting on my server.
Is this possible at all? If so, who would have to order the SSL cert - the current business for www.dogsittingservices.net - or me? How could I order a certificate for a domain I don't own? That's my dilema.
Thank you for any guidance/advice,
Mark
UPDATE following #EJP answer
So are these the steps I would need to take:
The business that has the website would setup in their DNS:
secure.dogsittingservices.net
They would then point that DNS to the IP address of my server
I would then setup a website on my server with the name: secure.dogsittingservices.net
I would then generate a CSR for it from my server
I'd then give the CSR to the business that I'm doing the work for
The business would then have to use the CSR I generated from my server, to order the SSL
They would then send me the SSL key/code to me to apply to my server
Is that how this is normally achieved?
Thank you,
Mark
They have to obtain their own SSL certificate. That's the whole point of them, that they definitely identify the business they are issued to.
You can also have one SSL certificate with multiple site-use, as an option. Read up more on SAN certificates as it may become relevant to your solution. This would allow you to share the certificate and suit both hostnames. You can also do a wildcard certificate as well if you may have more hostnames for that domain in the future.
I'm currently working on a project where I've created a CA cert and a couple of child certs to that CA cert. The certificates are going to be used to protect inter-server communication in a SAMLV2 setup so I'm going to have a cert for the identity provider and a cert for the service provider. The user/browser isn't going to validate the certs so it's only the servers that need to trust my custom CA. My cert tree looks something like this:
CustomRootCACert
CustomIdentityProviderCert
CustomServiceProviderCert
Now, I've heard a lot of people saying it's bad to use a home-made certificate in production. But when I ask why, people usually just mutters something about security but never go into the details. Are there any technical reasons not to use my own certs in production? I can't think of any... Of course I realize that if I lose control of my root cert anyone could start creating all sorts of certificates. But in this case they would also have to install the certificates on my servers and configure the saml application to use them. Only then could they start to generate fake saml requests and responses to my applications.
If this is the only problem, this solution (using home-made certs in production) would still be better than the login setup we have today.
Ask yourself what a certificate proves.
If you get a certificate issued by a reputable CA, then it proves that the certificate holder has verified their identity to that CA, to their standards of proof.
If you get a certificate issued by an ad-hoc CA, then it proves that someone knows how to make certificates.
If you control both ends of the conversation, I think it's fine to have your own private CA for the purpose. You would trust your own CA. You can probably make this very secure indeed (by keeping the CA private key in a safe place offline, and making signing a sneakernet exercise).
The difficulty would be if you needed to persuade anyone else to trust your CA. Why should they? You would need to convince them that it was safe to do so, and they would have the admin overhead of adding your CA certificate to their clients.
Since you are only using the certificate to protect the network traffic and not authenticate users/computers then it sounds like you have a legitimate use for using MakeCert.exe.
I feel there is one thing worth mentioning. After you spend some time working with the MakeCert.exe interface you might to consider using a Stand-Alone Root Certificate Server instead.
Consider these points:
(Almost) All versions of Windows Server include Certificate Server Services for free
Windows Stand-Alone CA Server is extremely simple to install and configure
Windows Stand-Alone CA Server can be installed on a Virtual Machine and turned on/off whenever you need to issue an additional certificate
A VM based Windows Stand-Alone CA Server can be run using very little memory (ex. 256mb)
Windows Stand-Alone CA Server includes a nice and clean web based enrollment interface to simplify requesting certificates.
CRL checking can be used or not used, depending on your needs.
In the past I first started with selfssl.exe and eventually moved to MakeCert.exe to generate a root certificate and then issued my client certificates. But after struggling with the syntax and always having to remember where I put that Root Certificate I switched over to using a Stand-Alone Root CA in a virtual machine.
IF the certificates are only passed around internally, between your own servers (and not used by the client, one way or the other) - then it is perfectly acceptable to use your own internal CA.
HOWEVER, one suggestion - dont have your Root CA issue your provider certs. Instead, use your Root CA to create an Intermediate CA - then use that to issue provider certificates. This will help you longer term, when you have to start managing certificate expiration, extending the system/infrastructure, revocation lists, etc.
There is no real issue with using a self signed certificate in private use, that is use when you control all of the systems that need to trust the homebrew root certificate.
You manually install your root cert onto each of the systems that need to trust it.
You can do this in production as well for browser use - for example within an organisation where the root ca can be rolled out via software distrubution method - there is no reason to go to the expense of paying a Certificate Authority that Microsoft happens to trust.
[edit]
In terms of secruity the issue is one of containing the private key for your root certificate, as long as you can ensure that stays private then you can validate any certificate off that root.