Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I really need to use SSL in my Socket Server\Client Communication but paying for a certification is too over priced for me :( i can't afford payed Certification
[Note] : my program will be publicly released so i wanna to secure my program communication with my server
The Question Is : Is it possible to use SSL\TLS for free in an effective [Without Security Riscs] way because i can't afford payed certificates... ?
Is it possible to use SSL\TLS for free in an effective way because i
can't afford payed certificates... ?
Yes it is. Buying certificates from a trusted CA, makes your server be trusted by all browsers without any manual action (e.g. Verisign).
If you own both the client and server and you are using SSL you can create your own certificates (or get free ones) and install them to all clients as trusted (in an off-line process).
The only part that relates to security now is the key size. Should be at least 2048 bits.
But there is one catch. If you create your own certificates you need to be careful what extensions you set so that you don't have any issues during deployment. The CAs know how to create X509v3 compliant certificates to be accepted by all browser (libraries) without any issues
Short answer: yes.
Long answer: What you're buying from a CA (certificate authority) is typically NOT a certificate. Typically, you create your own certificate, and ask the CA for a "signature", which you present to the client (browser, etc) in order to show that your certificate is trusted by that CA.
Browsers (and other software) typically have a internal list of CAs they trust. This is why one generally buys a signature - to have one's certificate recognized as valid by currently deployed software.
However, you are not required to get such a signature. You can just as well create your certificate (typically referred to as a "self signed" certificate) and either ask the end-user to introduce it to the software as trusted, or distribute it included in the software itself.
There are lots of instructions on how to create a self-signed certificate on the web, typicaly using the openSSL CLI, but also IIS, or Java.
As to how you deploy such a certificate on your software, you're better of asking another question.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'm developing a web application for use inside our internal Windows domain. I have 3 servers: apps.mycompany.com (primary), api.mycompany.com, and files.mycompany.com. Right now, everything works fine over HTTP. But I need to have these accessible over SSL/https to Windows desktop clients on the network (Chrome/Firefox/Edge) and iOS (Safari/Chrome).
I've set up self-signed certs using OpenSSL, and have configured nginx to where they respond correctly, and serve data. But, I'm constantly running into "not secure" / "invalid certificate" errors and "mixed content" (http/s) warnings that stymie my development. The errors on api and files are especially pernicious, as they just "break" things not obvious to the user.
I need a solution where everyone can simply hit https://apps.mycompany.com... and everything "just works", without user intervention (allowing insecure connections, manually adding certs, adding certificates to Trust stores, etc.)
Advice?
EDIT: I see this question was closed. Isn't setting up SSL/https an integral part of modern web development? (and yes, I had already asked my question on Server Fault).
You need to create a root certificate that would be trusted by all your clients. Then you can sign server certificates with that "root" key so that server certificates would also be trusted.
This is the example how you can issue such certs.
More challenging task is to install this root cert to all your clients. You can ask your domain administrator to help you with that. Otherwise you will have to ask all your users to install that root cert (they will also probably have to be local administrators..)
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 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've been struggling recently with using the standalone DartVM and SSL as a client. I'm of the understanding that Dart uses Mozilla NSS to manage the certificates. What I'm having a problem wit, is that on Windows, for example, there exists no binaries that I can find (other than third parties compiling the Mozilla source and uploading to mega or similar, which is pretty alarming if you ask me) released for the Windows platform. Compiling this C++ code is not a trivial task. I've not the resources to do so on my own under the Windows platform. This is why I write Dart (or other high level languages) in the first place.
Despite that, the error message I get when attempting to connect securely and being presented with a self-signed (or rather more technically correct, untrusted authority) certificate, is that the OS itself doesn't trust the certificate. On Windows, this is not the case. The certificate in question I'm using is a CA root certificate of my generating, with proper authority/signing chain, installed into Windows trusted roots manually. Both Chrome and Internet Explorer (of which use the Windows underlying certificate store) trust my certificate(s) without any warnings after having done this. So if the DartVM is not using the "OS" to validate a certificate upon handshake, then that message is very uninformative/misleading.
What can be done to overcome this outside of compiling NSS and trying to figure out just how to import my certificates by way of over-complicated and under-documented steps? Is there not a parameter that one could specify when initiating a secure connection to ignore SSL errors of this nature?
My web server forces the use of HTTPS so dropping back to plain HTTP would
not be an option for me. I also don't want to trust and much less want to pay a third party for my certificates of which are pretty much only used internally, which is why I generated a wildcard certificate under my own root CA in the first place. Paying for a wildcard certificate, for multiple domains, that aren't always necessarily exposed to the public or meant for public use is a bit astronomically priced and completely out of the question.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I want my site to use URLs like http://192.0.2.2/... and https://192.0.2.2/... for static content to avoid unnecessary cookies in request AND avoid additional DNS request.
Is there any way to obtain SSL cert for this purpose?
According to this answer, it is possible, but rarely used.
As for how to get it: I would tend to simply try and order one with the provider of your choice, and enter the IP address instead of a domain during the ordering process.
However, running a site on an IP address to avoid the DNS lookup sounds awfully like unnecessary micro-optimization to me. You will save a few milliseconds at best, and that is per visit, as DNS results are cached on multiple levels.
I don't think your idea makes sense from an optimization viewpoint.
The short answer is yes, as long as it is a public IP address.
Issuance of certificates to reserved IP addresses is not allowed, and all certificates previously issued to reserved IP addresses were revoked as of 1 October 2016.
According to the CA Browser forum, there may be compatibility issues with certificates for IP addresses unless the IP address is in both the commonName and subjectAltName fields. This is due to legacy SSL implementations which are not aligned with RFC 5280, notably, Windows OS prior to Windows 10.
Sources:
Guidance on IP Addresses In Certificates CA Browser Forum
Baseline Requirements 1.4.1 CA Browser Forum
The (soon to be) not-so Common Name unmitigatedrisk.com
RFC 5280 IETF
Note: an earlier version of this answer stated that all IP address certificates would be revoked on 1 October 2016. Thanks to Navin for pointing out the error.
Yep. Cloudflare uses it for its DNS instructions homepage: https://1.1.1.1
The answer I guess, is yes. Check this link for instance.
Issuing an SSL Certificate to a Public IP Address
An SSL certificate is typically issued to a Fully Qualified Domain Name (FQDN) such as "https://www.domain.com". However, some organizations need an SSL certificate issued to a public IP address. This option allows you to specify a public IP address as the Common Name in your Certificate Signing Request (CSR). The issued certificate can then be used to secure connections directly with the public IP address (e.g., https://123.456.78.99.).
The answer is yes. In short, it is a subject alternative name (SAN) certificate that contains IPs where you would typically see DNS entries. The certificate type is not limited to Public IPs - that restriction is only imposed by a signing authority rather than the technology. I just wanted to clarify that point. I suspect you really just want to get rid of that pesky insecure prompt on your internal websites and devices without the cost and hassle of giving them DNS names then paying for a CA to issue a cert every year or two. You should NOT be trying to convince the world that your IP address is a reputable website and folks should feel comfortable providing their payment information. Now that we have established why no reputable organization wants to issue this type of certificate, lets just do it ourselves with a self signed SAN certificate. Internally I have a trusted certificate that is deployed to all of our hosts, then I sign this type of certificate with it and all devices become trusted. Doing that here is beyond the scope of the question but I think it relevant to the discussion as the question and solution go hand in hand. To be concise, here is how to generate an individual self signed SAN certificate with IP addresses. Expand the IP list to include your entire subnet and use one cert for everything.
#!/bin/bash
#using: OpenSSL 1.1.1c FIPS 28 May 2019 / CentOS Linux release 8.2.2004
C=US ; ST=Confusion ; L=Anywhere ; O=Private\ Subnet ; EMAIL=admin#company.com
BITS=2048
CN=RFC1918
DOM=company.com
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/CN=$CN.$DOM"
openssl genrsa -out ip.key $BITS
SAN='\n[SAN]\nsubjectAltName=IP:192.168.1.0,IP:192.168.1.1,IP:192.168.1.2,IP:192.168.1.3,IP:192.168.1.4,IP:192.168.1.5,IP:192.168.1.6,IP:192.168.1.7,IP:192.168.1.8,IP:192.168.1.9,IP:192.168.1.10'
cp /etc/pki/tls/openssl.cnf /tmp/openssl.cnf
echo -e "$SAN" >> /tmp/openssl.cnf
openssl req -subj "$SUBJ" -new -x509 -days 10950 \
-key ip.key -out ip.crt -batch \
-set_serial 168933982 \
-config /tmp/openssl.cnf \
-extensions SAN
openssl x509 -in ip.crt -noout -text
The C/A Browser forum sets what is and is not valid in a certificate, and what CA's should reject.
According to their Baseline Requirements
for the
Issuance and Management of
Publicly-Trusted Certificates document, CAs must, since 2015, not issue certificats where the common name, or common alternate names fields contains a reserved IP or internal name, where reserved IP addresses are IPs that IANA has listed as reserved - which includes all NAT IPs - and internal names are any names that don't resolve on the public DNS.
Public IP addresses CAN be used (and the baseline requirements doc specifies what kinds of checks a CA must perform to ensure the applicant owns the IP).
It entirely depends upon the Certificate Authority who issuing a certificate.
As far as Let's Encrypt CA, they wont issue TLS certificate on public IP address.
https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082
To know your Certificate authority , you can execute following command and look for an entry marked below.
curl -v -u <username>:<password> "https://IPaddress/.."