Some big compagnies blocked my website by with their firewall. I don't know if I can do something for that. Will it be better If I use a self signed certificate rather than one signed by amazon ? What can be the issue of my website ? I have no idea.
It's almost certainly not personal. Big companies don't "dislike" your website, they probably don't even know it exists.
If you have a self-signed certificate, your site is being blocked by the major browsers because the certificate is invalid, not by any particular company.
The point of an SSL certificate is that it's traceable back to a trusted certification authority. A self-signed certificate is not from a trusted certification authority and will be trusted by nobody and blocked or at least warned about by all standards-compliant browsers.
If you have a self signed cert, the first thing you should do is get a real one.
If you're on a shared IP address, it's probably being blocked by a rule in a network appliance that is blocking the entire IP, not just your site. It's the internet equivalent of "living in a bad neighborhood and not being able to get pizza delivered". The problem isn't you; it's your some of your neighbors.
Get a real SSL cert. Then if you're still having problems, move your site to a "better neighborhood" (a better hosting provider).
Related
I want my site to be secure using HTTPS protocols. I managed to make a self-signed key to be trustedCertEntry as I made my own CA certificate, with different CN, which I used to sign my own private certificate.
It works smooth testing it with openssl with something like:
openssl s_client -connect www.mydomain.com:80 -tls1 -state
Thus, browser doesn't report a certificate self-signed error, as it sees a different CA.
But I get a SEC_ERROR_UNKNOWN_ISSUER error. Still it seems logical to me as nobody knows me as a CA. It is supposed to work if user adds exception for me.
I thought this trick was acceptable and it was like many https compliant sites were working, as you may visit a unknown site and you want to encrypt communications from 3rd party watchers but trust that page.
After trying to get a clear response for it, beyond coding that I will find resources, my question is:
If I want to have a site, for which the users don't have to add an exception in the first visit, do I have to get a certificate from a "world-known" CA? Or am I missing a solution for self-signing my certificate with my own CA certificate?
Technically speaking, the answer is: Yes, you will have to get a certificate from a CA that is trusted by your users' browsers via a chain of intermediary CA's that ends at an inherently trusted root CA. The accepted answer to this question explains how it works: SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
Having said that, if your "only" concern is to provide encrypted connections, you might be able to leverage the Let's Encrypt CA, which provides free certificates for that purpose. Those certificates will be only domain-validated, which provides a weaker kind of assurance of identity than, for example, an Extended Validation Certificate.
Depending on the browser used, there will be minimal difference in user experience between DV and EV certificates. For Safari, the user will see a grey padlock in the address bar for the lower assurance DV-backed sites, like this:
and a green padlock when higher identity assurance is provided, like this:
Whether the former is good enough for you (or your customers) depends on your situation.
In case you want to understand what "inherently trusted" actually means for web browsers, see this blog post: Who your browser trusts, and how to control it.
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 Want to authenticate systems deployed on different servers with each others using certificates. If it wasn't a self-signed certificate, what should it be to let each system has its own certificate and trust in in the other server in the production environment?
The signed certificates are paid and I don't think I need them since I don't have user interaction. Am I right?
The distinction here is not really "self-signed" vs "signed." The correct distinction is "commercial" vs. "internal." Commercial certificate vendors are selling you exactly one thing: they have a certificate in the root store of major browsers and operating systems. There is no technical difference between a certificate that Verisign signs and one that you sign. Verisign just has a signing certificate in this list and you don't.
So you're correct. For internal authentication, there is no security reason to favor commercial certificates. You still have to protect your private key just as carefully. Commercial certificates offer convenience, not security. You pay them some money, and you don't have to worry about some of the configuration.
But you can trade convenience for money. There are two ways to do that: internal roots and certificate pinning. With an internal root, you just create some signing root certificate (a "Certificate Authority") and put it in the trusted root stores of your servers. Then issue CSRs (certificate signing requests) to yourself, sign them, and apply those to your services.
Certificate pinning just skips the Certificate Authority step. Just take all of your service certificates, and put them directly into the trusted root stores of your servers. Then there's no indirection.
Each way has its advantages. I tend to prefer pinning all other things being equal because it ties me to specific certs rather than chains. But either way is really fine.
The specifics of course are going to be highly dependent on your toolchain, which you didn't list, but your question suggests you already know how to create the certs.
Just remember that your security is going to be dependent on protecting your private keys. But that was true with commercial certificates, too.
You didn't say what platform you are using, but for Windows I would recommend Active Directory Certificate Services: https://technet.microsoft.com/en-us/windowsserver/dd448615.aspx
I am interested in web security right now. So I read about PKI and Diffie Hellman authentication forms.
Now I am reading about certificates and I ask me how that works. So I know Browser have some trusted certificates in it, so you trust the pages, the company which the browser is from, trusts already. So when A trusts B and B trusts C --> A trusts C. Standart Web-of-trust thing.
But what I don't get is how for example google did it when they made there applications https. I never had to download a certificate. How works that?
There are a number of commercial bodies whose business is the issuance of digital certificates; these are called "Certificate Authorities" or CAs. The certificates of the top-level keys of these bodies are distributed with the common web browsers, so you will already have them installed.
If you (or Google, or anyone else) want a certificate for your key you send a request (and some money) to one of the well-known CAs. The CA performs some checks to verify that you are who you say you are, and (as long as the checks check out) they make a new certificare by signing your key with their certificate-signing key.
When you send your certificate to some third party they can check your certificate using the CA's certificate stored in their browser, and this allows them to establish that the identity you claim in your certificate is correct.
There are various levels of certificate which carry different levels of guarantee that the identity claimed in the certificate is correct. Basically, the more you pay the more trouble the CA takes in checking your identity and the more insurance they buy!
All browsers store certificates of Certification Authority, who in turn issue certificates for various organizations.