This question already has answers here:
Is a self-signed certificate secure enough?
(3 answers)
When is it acceptable to use self-sign cert in production?
(2 answers)
Closed 1 year ago.
I am attempting to securely communicate between two embedded devices.
One (referred to as the server) is acting as a WiFi access point, similar to a router. It runs a HTTP server at a constant IP address. My goal is to enable SSL on this server.
The other (referred to as the client) connects to the server's WiFi access point and makes request to the HTTP server in order to provide the server with information it needs to operate.
Every example I can find that attempt this uses self-signed certificates. From my (limited) understanding of TLS, these are not secure and should only be used for development.
I believe what I want is a trusted certificate. However, every example I can find generates these certificates for websites. I am struggling to understand:
If it is possible to generate trusted certificates for this application, and
How to do so.
Any help is appreciated!
Related
I've been investigating the possibility of migrating to using Let's Encrypt to maintain the SSL certificates we have in place for the various resources we use for our operations. We have the following resources using SSL certificates:
Main website (www.example.com / example.com) - Hosted and maintained by a 3rd party who also maintains the SSL certificate
Client portal website (client.example.com) - IIS site hosted and maintained by us on a server located in a remote data center
FTP server (ftp.example.com) - WS_FTP Server hosted and maintained by us on a server located in a remote data center
Hardware firewall (firewall.example.com) - Local security appliance for our internal network
Remote Desktop Gateway (rd.example.com) - RDP server hosted and maintained by us on a server located locally
As indicated above, the SSL certificate for the main website (www) is maintained by the 3rd-party host, so I don't generally mess with that one. However, as you can tell, the DNS records for each of these endpoints point to a variety of different IP addresses. This is where my inexperience with the overall process of issuing and deploying SSL certificates has me a bit confused.
First of all, since I don't manage or maintain the main website, I'm currently manually generating the CSR's for each of the endpoints from the server/service that provides the endpoint - one from the IIS server, a different one from the RDP server, another from the WS_FTP server, and one from the hardware firewall. The manual process, while not excessively time-consuming, still requires me to go through several steps with different server systems requiring different processes.
I've considered using one of Let's Encrypt's free wildcard SSL certificates to cover all four of these endpoints (*.example.com), but I don't want to "interfere" with what our main website host is doing on that end. I realize the actual certificate itself is presented by the server to which the client is connecting, so it shouldn't matter (right?), but I'd probably still be more comfortable with individual SSL certificates for each of the subdomain endpoints.
So, I've been working on building an application using the Certes ACME client library in an attempt to automatically handle the entire SSL process from CSR to deployment. However, I've run into a few snags:
The firewall is secured against connections on port 80, so I wouldn't be able to serve up the HTTP-01 validation file for that subdomain (fw.example.com) on the device itself. The same is true for the FTP server's subdomain (ftp.example.com).
My DNS is hosted with a provider that does not currently offer an API (they say they're working on one), so I can't automate the process of the DNS-01 validation by writing the TXT record to the zone file.
I found the TLS-ALPN-01 validation method, but I'm not sure whether or not this is appropriate for the use case I'm trying to implement. According to the description of this method from Let's encrypt (emphasis mine):
This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers, but mainstream web servers like Apache and Nginx could someday implement this (and Caddy already does).
Pros:
It works if port 80 is unavailable to you.
It can be performed purely at the TLS layer.
Cons:
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
Like HTTP-01, if you have multiple servers they need to all answer with the same content.
This method cannot be used to validate wildcard domains.
So, based on my research so far and my environment, my three biggest questions are these:
Would the TLS-ALPN-01 validation method be an effective - or even available - option for generating the individual SSL certificates for each subdomain? Since the firewall and FTP server cannot currently serve up the appropriate files on port 80, I don't see any way to use the HTTP-01 validation for these subdomains. Not being able to use an API to automate a DNS-01 validation would make that method generally more trouble than it's worth. While I could probably do the HTTP-01 validation for the client portal - and maybe the RDP server (I haven't gotten that far in my research yet) - I'd still be left with handling the other two subdomains manually.
Would I be better off trying to do a wildcard certificate for the subdomains? Other than "simplifying" the process by reducing the number of SSL certificates that need to be issued, is there any inherent benefit to going this route versus using individual certificates for each subdomain? Since the main site is hosted/managed by a 3rd-party and (again) I can't currently use an API to automate a DNS-01 validation, I suppose I would need to use an HTTP-01 validation. Based on my understanding, that means that I would need to get access/permission to create the response file, along with the appropriate directories on that server.
Just to be certain, is there any chance of causing some sort of "conflict" if I were to generate/deploy a wildcard certificate to the subdomains while the main website still used its own SSL certificate for the www? Again, I wouldn't think that to be the case, but I want to do my best to avoid introducing more complexity and/or problems into the situation.
I've responded to your related question on https://community.certifytheweb.com/t/tls-alpn-01-validation/1444/2 but the answer is to use DNS validation and my suggestion is to use Certify DNS (https://docs.certifytheweb.com/docs/dns/providers/certifydns), which is an alternative managed alternative cloud implementation of acme-dns (CNAME delegation of DNS challenge responses.
Certify DNS is compatible with most existing acme-dns clients so it can be used with acme-dns compatible clients as well as with Certify The Web (https://certifytheweb.com)
This question already has answers here:
How do certificate avoid the man in the middle attack?
(1 answer)
SSL and man-in-the-middle misunderstanding
(5 answers)
How are ssl certificates verified?
(6 answers)
Closed 1 year ago.
Was reading HTTPS workflow and would like to understand more about it.
Client ---> Malicious Server (instead of actual server)
When Client connects to server there can be possibility that it connects to malicious server and that server represents the certificate on behalf of Actual Server, how client knows whether its genuine server or not?
I am investigating the use of SSL to ensure security when performing remote software updates to embedded systems. This means that I would like to ensure that only specific client machines may communicate with the embedded server system.
I understand that server certificates authenticate the identity of the server and client certificates authenticate the identity of the client and this prevents man in the middle attacks.
What I would like to know is if client certificates can be used in such a way that only clients with specific certificates, compatible with the server, can communicate with the server.
My interpretation so far from reading up on this is that that certificates are used to ensure that either client or server are who they say they are. Not to restrict access to specific clients. Is this correct?
If someone could help clarify this, and provide some pointers, I'd be grateful.
Thanks
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 have a WCF service hosted under IIS 6.0 running under Windows 2003 R2. The service is SSL secured with "Required client certificates" option.
When I browse the service from IE within win 2003 R2, I am able to see the WSDL.
When I try to browse from my development machine running IE on Win XP. I see 403.7 error like this.
The page requires a client certificate
......
......
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I have spent 5 days on it tried everything possible like
Checking the client certificate on Client, private key, importing it again and again.
Checking its intended purpose (client Authentication) and EKU value.
Checking the CA is installed on both server and client in Trust Root Cert Authority Folder.
Running SSL Diag tool. Unfortunately it shows the message which i pasted above and not much detail.
It works when I try the option "Accept Client certificates" under IIS Directory security tab.
Is there something that I am missing or unaware of it?
Finally with the help of MSFT support, I have resolved it.
The reason was, on the webserver there were too many certificates in the Trusted Root Certificates Authority folder that it exceeds the recommended length. Hence i got this warning in eventlog.
When asking for client authentication, this server sends a list of
trusted certificate authorities to the client. The client uses this
list to choose a client certificate that is trusted by the server.
Currently, this server trusts so many certificate authorities that the
list has grown too long. This list has thus been truncated. The
administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that
do not really need to be trusted.
I did delete some the the expired/unused certificates but still it wasn't sufficient. I couldn't delete more certificates due to fear of breaking the system because they were not expired.
We used method 3 to fix the problem which is discussed here
Though it had fixed my problem but only draw back of using this method is, client browser will present you the list of all client certificates present in the computer instead of choosing which one server wants based on the Trust Root CA.
This works for me because I have a WCF service and not a website.
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 have an SSL assigned to my main domain and I'm wondering if I can use the SSL to my sub-domain!! I frankly tried it out, but it shows warning page saying that this page is not safe or so on. Is there a solution to this so I can use the SSL on my sub-domain to let clients send their info on a secure connection.
The error message " This webpage is not available"
X.509 certificates (often called "SSL Certificates") are usually only bound to a single domain, usually mydomain.example, www.mydomain.example or secure.mydomain.example. They cannot be used on any other domain name, even if it's a subdomain (so a certificate for mydomain.example cannot be used for www.mydomain.example and vice-versa).
There currently exist 2 other types of certificates which can be used to simultaneously secure multiple domain names simultaneously:
A relatively new type of certificate called an "SAN Certificate" - short for "Subject Alternative Name" - also sometimes called "Unified Communications Certificates" after a feature in Microsoft Exchange Server which requires this certificate type. These certificates declare a finite list of hostnames they can be used against.
Then there's wildcard certificates. Historically these were very expensive but recently we've seen a huge drop in price. With one of these certs you can secure anysubdomain.mydomain.example including the top-level mydomain.example.
Without either of these SSL certificates you'll need to get an SSL cert for each domain name you want to secure.
Note that having a different certificate for each hostname/domain-name can cause problems because the TLS system establishes security for the channel before the HTTP Host: header is sent - this means that each secured website will need its own IP address or port number.
...unless you use SNI (Server Name Identification) certificates. The good news is that all modern browsers and servers support it SNI, so multiple secure websites can share IP addresses and port bindings with their own certificates (so without needing a single SAN certificate that lists all domains on it).
The bad news is that Internet Explorer on Windows XP cannot connect to SNI websites (but Chrome and Firefox are okay), and on the server-side you need at least Windows Server 2012 or later. So adopt SNI based on how popular IE+XP usage is.