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.
Related
Context:
I have an application that is deployed to each client as a Virtual Machine. The latter is installed by the clients wherever they want (I don't necessarily know the final domain). The application comprises an JBoss Web Server that provides access to a configuration page, protected by SSL. Right now the server is using a self signed Certificate. However, I want the browsers to stop showing the warning messages associated to self signed certs. Moreover, I provide a free version of the application that has basic functionality.
Question:
For cases where the client is using a free version (and me wanting to reduce costs), what is the best approach when using a SSL cert, and not knowing the final domain (most of the time)?
It is acceptable to use a self-signing cert? If so, a different one
per client install?
Is it best to issue a new cert (maybe a free one) for each
deployment?
Is is acceptable to use the same cert, signed by a proper CA, on all
of the deployment VMs?
A completely different approach?
Thanks guys!
It is acceptable to use a self-signing cert? If so, a different one per client install?
Ask your clients. Will they put up with a browser warning? or not?
Is it best to issue a new cert (maybe a free one) for each deployment?
It is best for the client to acquire his own SSL certificate. You can't do that for him. Nobody can.
Is is acceptable to use the same cert, signed by a proper CA, on all of the deployment VMs?
No, it entirely defeats the purpose. The certificate and the private key it wraps are supposed to uniquely identify the holder.
A completely different approach?
Handball the whole megillah to the clients. Self-identification is their problem, not yours.
I have godaddy ssl certificate for domain.There wasn't any problems with my SSL certificate and visiting my domain(Haven't receive any errors), but couple times(two weeks ago) when I visited site from other(mobile, tablet and desktop) devices(different internet) I received SSL warning. I tested my domain on sslshopper.com and in this system shows that everything is okay with our SSL(Expiry date in 200 days). But I tested my SSL in ssllabs.com and SSL got only C grade. Maybe you have any idea why such stuff happening? Is it possible that if we would change SSL to other one, there wouldn't be such error at all? Maybe you experienced something similar and you can help out. Because warning appears only sometimes and in different devices, but other than that everything is perfect
When some client devices show problems, and others don't, it must likely because some client's don't contain the necessary Intermediate or Root Certificate Authorities to establish a chain of trust.
This is not the fault of the client device.
Rather, it is up to the server-side (ie. the side sending its certificate) to supply enough of the chain (ie. its certificate, and its CA certificate(s)) so that the client can use those to fill in the steps in the chain until it gets to a certificate that is signed by another certificate that it has in its trusted CA keystore.
You're very likely only supplying the server certificate.
Also possible, but generally less likely, is that the certificates are being offered by the server in the incorrect order.
To help you further, we would need to have some details as to what software is implementing the SSL server end-point.
Cheers,
Cameron
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.
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 am managing a number of websites that use SSL certificates and have had a few complaints from individuals that are not able to view some of these sites in secure mode. The problem persists regardless of browser or version that is used, does not affect viewing in non-secure mode, and only occurs with a few of the secure sites, not all. Each site has a separate SSL certificate.
I don't have any idea what may be causing this problem or how to address it and would appreciate any helpful questions or ideas that would contribute to fixing it.
Just a hunch, but one possibility could be that weak ciphers are disabled on the server and strong ciphers are not enabled on the client. Another possibility might be that the root certificates list on the client is not up-to-date and the SSL certificate is signed by an authority that is not in the trusted list.
They key here is to find out what they all have in common. Maybe they all use AOL? Behind a caching proxy? Can they view other secure sites? Maybe they have a virus or trojan causing the issue?
Maybe they are behind some proxy that is performing interesting operations of SSL connections?