I have SSL working fine in production but have some issues locally.
When I run the site it opens 2 tabs, one http:// and one https://
I want to just use the http:// tab locally for testing. When I go to a page that requires https I get the error:
Unable to make a secure connection to the server. This may be a
problem with the server or it may be requiring a client authentication
certificate that you don't have
I have added the certificate to:
Persona/Certificates
Trusted Root Certification Authorities/Certificates
Intermediate Certification Authorities/Certificates
Everything works fine locally when I use the https:// tab.
Do I need to add the certificate somewhere else too?
Using SSL certs locally is always a challenge. When the website opens, it's likely using the loopback IP (127.0.0.1) which will always (rare exceptions, perhaps, that I can't think of) give a certificate error, because the cert is bound to a domain name, not an IP. Ideally you'd probably want to not use your websites real SSL cert locally anyway for security reasons.
You can use a self signed cert for localhost, which should work:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/32bc5a61-1f7b-4545-a514-a11652f11200
Also, I just blogged a code snippet we've used before -- in short, it just avoids using SSL for local connections and otherwise lets you define which pages/folders should otherwise be SSL protected...
http://www.structuretoobig.com/post/2013/02/19/Skipping-SSL-Connections-Locally.aspx
Related
we have an web application(WAMP stack) on a local Windows server. There are several dependencies and an Oracle db running on this server and the server is closed to outside internet traffic.
Clients access the app on LAN using the server's IP, but we plan to create a virtual hostname in active directory to enable access using a hostname on entire local network.
We would like to secure the traffic and switch to https, thus we need a SSL certificate, preferably from a trusted CA to avoid any confusing warnings to the users.
Is there a way to get a Trusted CA SSL certificate for a local host? I was thinking of getting a certificate for a public domain, say myapp.net, then map this domain to actual ip of the local server running the app and install the certificate in apache... would that work?
Thank you for any ideas.
Alexander
You have several options:
The public CAs that your browser trusts by default will only sign keys for DNS names. And you can totally have a DNS name that is not accessible from the public internet (e.g. one that resolves to a local IP). In case you're using CAs like LetsEncrypt (Domain Validated), you will need to make the server available publicly during the key exchange/certification time, but can change the IP immediately afterwards (*). Or simply use one of the other available validation techniques - typically they're paid.
As you're on the intranet, you might be in a situation where you can install your own internal trusted CA on your users' computers. In that case, you can mint such a certificate yourself. This is a scenario that's common in case there's a proxy running internally that's also inspecting https traffic.
And, of course, in case you can install trusted root CAs on computers, you can also install individual trusted keys/certificates for a single machine. But that seems not to be what you'd like to do.
So, for https://myapp you'll have to do some minting/installation yourself. For https://myapp.example.com, you have options with (already) trusted root CAs
(*) that is for the commonly used and documented mode-of-operation. See Patrick's comment below
I have spent 2 days trying various solutions breaking the stack multiple times... you are my only hope:)
I have setup Plesk on an aws instance and i'm using a webhost license.
Set up a hostname, issued a certificate with lets-encrypt, and works fine when accessing the admin interface on hostname.com:8443
Set up a client domain, issued certificate with let-encrypt, works fine for the front end but when i want to enter admin on clientdomain.com:8443 i get a privacy error. Same thing when trying to access admin with the server ip only as well. In both cases it tries to pull the certificate of "hostname" instead of the cert issued to the client domain.
The goal is to get clients clientdomain.com:8443 and server ip working with ssl or to redirect to hostname.com:8443
I would like to understand what's happening and how can i fix it.
Just in case someone stumbles across the same issue:
Currently this is not possible in Plesk (Obsidian18.0.27) but its being considered
As a temporary solution the best practice is to redirect all clientdomain:8443
requests to hostname:8443 and force https to ensure secure connection.
To achieve this follow these instructions:
https://support.plesk.com/hc/en-us/articles/115001421414
We're having an issue with securing an intranet / internet website with SSL where
we can't know the qualified domain name in advance.
Basically, I'm trying to make a program that will be installed on a webserver
outside my direct control, to be accessable over intra- or internet. In either case
I want it to be secure via SSL (https). To do this, I would like to include and
install a SSL certificate on the target machine. My installer is fully prepackaged
and should not require any particular during- or postinstall intervention from my
end. Problem is, I can't know ahead of time the target machine's name or domain
name, so as far as I can tell the SSL connection will be returning warnings (or
worse?) when accessed, since the certificate I include will (must) have a different
name on it.
I really want to avoid those warnings, but I still want to keep it secure. Is there
any way to install a SSL connection without certificate warnings without the domain
name known ahead of time?
Thanks for any help you folks can give.
What you want to do is not possible. Here's why.
A certificate will include a set of names (Common Name, possibly along with Subject Alternative Names, possibly including wildcard names).
The client's web browser will do the following:
The user wanted to visit "https://myapp.mydomain.com/blog/posts/1".
The request is via SSL and the domain name in the request is "myapp.mydomain.com".
Get the certificate from the Web server.
Ensure that at least one of the names in the certificate is exactly equal to, or wildcard-matches, the domain name in the request.
Display the page.
Therefore, you need a certificate with the exact domain name (or a wildcard matching the exact domain name) by which the application will be used. And the certificate needs to be available at the same time as, or later than, the time when the exact domain name of the website becomes known, and cannot be made available any earlier.
You seem to be under the misapprehension that somehow a certificate can "create" or "install" an SSL connection. That is false. The Web server - Apache, IIS, Nginx, LigHTTPD, or whichever one you happen to use - is the program that knows how to every aspect of SSL connectivity. The certificate is just a file that the Web server sends to the client, without even opening or using in any way.
Additionally, the author of a webapp to be distributed is not responsible for creating or distributing certificates, and should not be under the misapprehension that he is responsible. Only the website maintainer should be responsible for obtaining a certificate for his website. As another person remarked, in your installation process or perhaps in a post-installation process, you may ask the person installing the webapp for a certificate. But that is the best you can do.
The best you can do is to buy a wildcard SSL certificate - but wait, it's not what you think. You still need to know the second-level domain (the TLD being ".com") ahead of time. You can effectively ask for a cert that covers *.foo.com - then any site, a.foo.com, b.foo.com will be covered. Of course, these certs are more expensive that FQDN certs because you are doing the buggers out of some extra coin.
-Oisin
Each of those sites should have their own SSL certificate. Why not prompt the user to provide the cert file during installation?
In most (if not all) cases, the SSL certificate is associated with the webserver (apache, IIS, etc.) and is not part of your application. It's up to the admin of the web server to install the certificate and not you as the author of the program.
If your installation program does have the ability to modify the web server configuration, and you are willing to have it use a self-signed certificate, you can script the creation of the certificate to allow the domain name to be input. However, I sense this is not really available to you. Also, a self-signed certificate will generally cause certificate warnings.
If I understand you correctly there might be a solution to your problem now. This solution won't help you, however, if you have no control over specifying what SSL certificates are served from the web server where your program is installed (as mentioned by someone else). If your program itself contains a web server you won't have this issue.
If you start with a trusted https website, you can make cross-domain TLS (SSL) XmlHttpRequests to the web servers that are running your application. This is made possible using the opensource Forge project. The project uses a TLS implementation written in JavaScript and a small Flash swf to handle the cross-domain requests. Your program will need to serve an XML Flash policy file that grants the trusted website access to the web server running the application.
Your program will also need to generate a self-signed SSL certificate and upload it to the trusted website. From there, each program's certificate can be included as trusted via the JavaScript TLS implementation. Alternatively, you can have your program upload its certificate to be signed by a CA you create, using a common or subject alternative name that is appropriate for your use (it doesn't have to be the domain name). Then you can use JavaScript to trust the CA certificate and look for the correct name on each certificate.
For more details check out the Forge project at github:
http://github.com/digitalbazaar/forge/blob/master/README
The links to the blog posts at the end provide more in-depth information about how it works.
Here's a possible scenario.
Let's say I have a website "https://www.mywebsite.com" and there is a valid SSL certificate purchased for this domain.
I want to "mimick" this website on my LOCAL machine for a testing purpose.
So let's say I set up a locally-configured "https://www.mywebsite.com" (which is in essence https://localhost/mywebsite or something similar).
Would I be able to re-use the SSL certificate on my local testing website?
You can re-use your SSL certificate if you configure your DNS so that your test machine is the same domain name as server, which is probably a bad idea.
You can also re-use it on your test machine if you don't mind clicking the box "accept this whacked out ssl cert"... So I suppose that the answer is technically yes, although I wouldn't personally do it.
It depends what you are trying to test and why you need a certificate for testing.
If you use the certificate, it will correctly encrypt connections using SSL, but any client will get a certificate mis-match error. If you use a self-signed certificate instead, most clients will give you a warning about that, so it might be just as annoying or not.
If you are testing, for instance, a deployment script to make sure everything gets installed in the right place, it will work. If you are testing to make sure your code correctly redirects a non-secure connection to a secure one, it will work.
If you want to test the your website for functionality, usability, bugs, etc. then your testers will likely complain about the certificate warnings or errors, and you're probably better off doing something else.
I am not sure since the SSL certificate is bound by the domain name that was registered with the certificate. But you may be able to dupe the certificate by editing your hosts file to change localhost 127.0.0.1 to be mysite.com 127.0.0.1, ...in theory at least...if not this is a question for serverfault.com.
Hope this helps,
Best regards,
Tom.
You can't use it since the SSL cert is tied to the domain www.mywebsite.com unless you do a bit of trickery.
You can put an entry in your hosts file saying that domain is at 127.0.0.1, but that's not ideal as you could no longer reach the website.
If you just need a valid cert to test with, then a better alternative is to self-sign using the IIS Resource Kit.
I'm no expert on DNS, but this would introduce a pretty major vulnerability.
Basically if this was allowed, DNS poisoning could be used defeat the whole purpose of third party trust.
Think about it:
I infect your computer so that when you go to www.amazon.com it resolves www.amazon.com to a different domain. That domain uses amazon's ssl cert to fool you into thinking it's legit, so you send me your credit card information.
So, the answer to your question is, no you can't do this. You will still get errors, My guess is that somewhere on the verfication chain, it compares the domain that initiated the request with what its internal dns resolves the domain, to verify there is a match.
As others have said, you can test SSL with a Self Signed Cert, you just have to instruct your testers to import the cert, or go through the trouble of building your own trusted CA, and have testers add that CA as a trusted CA.
There is no point in stealing another sites SSL Cert.
Of course you could use the vulnerability in MD5 to create your own valid SSL cert.
http://www.digicert.com/news/2009-01-05-md5-ssl.htm
I've got an ssl certificate for what I think is my domain and I want to apply it to two separate applications in that domain that run under ASP classic in IIS on Windows 2000.
I have the following stupid questions:
Are certificates issued for URLs or domains? Or subdomains?
Can I use the same cert for multiple websites (applications) within that domain, or do I need a separate one?
Can I inspect the cert file to determine for what or to whom it's issued?
Thanks!
1) Web certs are issued to a domain. Specifically the CN attribute of the certificate must match the domain used to access your site.
2) Certs are usually install per host (or virtual host). If you had cert for the domain wwwapps.domain.tld you could have one app at /calendar, and one app at /contacts.
3) Yes, depending on the format and where it is, this can be easy or hard. If you have a crt file and you are running under windows, just click on it. You should see the details.
If you want to inspect a certificate that is installed on a site, you usually have to click on the padalock icon.
On windows you can also open up the MMC, add the certificate snapin and see any/all installed certificates on the local machine, or your profile.
They are issued for domains. Subdomains require their own certs. You can buy a special wildcard cert for your domain that lets you create certs for your subdomains, but they are more expensive.
If you buy a cert for mydomain.com, you can use it for anything that starts with https://mydomain.com/
Yes. You can do this for any certs. check out the lock icon in your browser's address bar.
It's usually issued to a single web server host (basically a computer cname or a record) like foo.bar.com where foo is one name for the host which the certificate request was generated for and bar.com is its domain.
Thus it will work for any application or virtual directory that responds to https://foo.bar.com - like https://foo.bar.com/planner/ - but nothing more.
For https://*.bar.com you can get a wildcard certificate that lets you handle any number of hosts without any hassel - at a greater cost.
There are also multiple-SAN (UCC) certificates that can contain a specific number of host names in a single certificate like webmail.bar.com and autodiscover.bar.com for an Exchange 2007 server serving both web access and Outlook Anywhere from the same physical machine and NIC.
If it's in .cer format simply opening it in Windows will show the details, if it's a pfx or in some other transport format you'd need to import it.
You basically install the certificate on a Web Site node in IIS and anything you can fit beneath that (or modify using a modern firewall in front of it to still respond to the issued common name foo.bar.com) will work.
Thanks! I enabled port 443 for the site at the domain on the cert, loaded the cert via directory security in IIS for each subfolder, and enabled 128-bit encryption. Worked like a champ!