I set up shellinabox on my linux box to access my PC from work and registered a domain name (goofy as in developer_forums so as to fool the admins) but there is one little loophole the https site (my pc) does not have an SSL certificate. How can i fix that ?
These kind people will generate you a free ssl certificate and provide installation instructions
http://www.startssl.com/
That said I agree with what was suggested in your comments, ssh would be a better, safer and easier way to get the same result.
Related
I know very little about code signing and haven't been able to find out any definite answer on the internet about this : is it possible to use a single SSL certificate for running an HTTPS server and code-sign Windows executables at the same time?
If yes, what are the advantadges/drawbacks?
I'm not quite sure if this question applies to this forum but if it does maybe someone knows if it is possible using Open SSL to create a SSL sertificate that browsers wouldn't throw warning messadges that our created SSL sertificate is untrusted?
Technically it is possible if you have CA's private key to sign the newly created certificate. As you probably don't have a key, the answer is probably no. Just go ahead and purchase a certificate from one of CAs. If you do minimal research, you will find that some CAs offer very affordable prices.
This is probably better handled on server fault, but I will tell you that NO you cannot do this. The reason browsers don't like your certificate is that you are not a recognized certificate authority. As such, a browser will always warn about your certificate being untrustworthy, since the browser does not know who you are, or why anyone should trust you.
EDIT: As Alex K points out, you can install your certificate on machines you know will access your site, which works reasonably well for scenarios where the site will only be accessed by a limited number of known users/machines. My point still stands regarding wider distribution. Thanks, Alex.
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'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)
Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.
Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y
Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?
Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.
You have two practical options:
Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.
Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.
I did the following, which worked nicely for me:
I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)
I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".
I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.
You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com
Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.
Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.
In short: To make the cert trusted by a workstation you'd have to either
change settings on the workstations (which you don't want) or
use an already trusted party to sign your key (which you're looking for a way around).
That's all your choices. Choose your poison.
I would have added this as a comment but it was a bit long..
This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.
I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.
If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.
I had a similar requirement, have our companys browsers trust our internal websites.
I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.
Heres the writeup for this,
https://medium.com/#mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
i think the answer is NO.
out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.
you can only get a verified certificate for a globally unique domain.
so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.
also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.
(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)
Development purpose only
This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.
It launches a reverse proxy in the port 443 with a public cert that works with any *.my.local-ip.co domain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:
$ APP_URL=http://192.168.10.10:8080 docker-compose up
The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.
The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).