I’ve been tasked with setting up a RODC on a DMZ with a one way trust.
The kicker is that the RODC is also to be it’s own one off standalone domain.
I’m not sure if this is something possible.
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)
The context:
I currently have a multitenant site (sub1.maindomain.com) and I am working on adding several other sites. Some of the new sites (sub2.maindomain.com, secdomain.com, ...) will probably also be multitenant.
I have certificates for each site I add, but only one IP address.
I'm working on Windows Server 2012, IIS 8.5.
The problem:
In order to allow multiple certificates I have to enable SNI in the https binding. Once I enable the SNI for the multitenant site (therefore editing the hostname) subdomains are no longer recognized (therefore no multitenancy).
Changing/Renaming/Restructuring the sub1.maindomain.com domain is not a real option, since it's being used by active clients for hosted pages among other things.
So far:
I am considering a wildcard certificate on which I can have the domains for all sites, (*.sub1.maindomain.com, *.maindomain.com, *.secdomain.com, ...) but I read that some browsers might have an issue with it and it is not recommended.
EDIT: It's been confirmed to me that I cannot consider the wildcard certificate option, mainly because of the price.
I have also tried using the Application Request Routing to solve the issue as described here but so far I it hasn't panned out.
From what I've tried so far I am either getting certificate errors in some or all of my sites, or "turning off" the multitenancy for the multitenant sites.
Any ideas on how to proceed?
Since we have a single multitenant app we allocated a second IP, given also that the cost is acceptable. The multitenant app is on one IP, the single tenant apps are all hosted on the other IP using the SNI feature to enable the use of multiple certificates.
Enviroment
Consider the following production environment setup for a web application:
End user --Internet--> web server in DMZ --Firewall--> WCF hosted on app server --> DB Server
Constraint:
Also consider that we cannot change anything from the infrastructure point of view. For example, open ports, change any firewall setting etc.
Problem:
We want to expose the WCF, which is hosted on the app server, to external clients. We are trying to solve this as follows:
End user --Internet--> Router WCF in DMZ --Firewall--> WCF hosted on app server --> DB Server
Please note that we cannot establish a db connection from the DMZ environment where the WCF needs to be hosted so that the external clients can consume it. We have developed a "Router WCF" which passes through all messages to the internal WCF and vice-versa.
This solution adds an unnecessary overhead of serializing and de-serializing data. There must a better and proper way of doing this. We are looking forward to the community for guidance. Thank you.
In DMZ the bibliography tells you: always create an intermediate layer. This means another machine on the internet will be the point of connection and it will proxy the connection back to WCF.
The machine is the web server you seem to mention, that is stupid, has no data, and (to be a proper DMZ) has a firewall between it and all the machines (WCF and the others) it serves that permits only IP:PORTS used on such machines.
In this scenario, usually Apache on the public web server with a URL-rewrite rule (i.e if it is /x/y send it to servera.internal.com:9900 - if it is /x/z send it to serverb.internal.com:9901 etc...) is enough, but there are plenty of solutions of course.
It seems you are doing exactly this, why do you say it is not the proper solution?
DMZs could seem a bit dated as protection mechanism (I agree) but you have to think when servers like your WCF machine had dozens of ports opened, and you wanted to lower the risk of random ports on web-facing machines, a giant attack surface. Nowadays everything can work with couple of ports opened, so it can seem "silly" to do all of this just to forward a TCP port. But it is still valuable as (for example) if servers behind the web server in DMZ do not have internet access, even when WCF is compromised, the attacker cannot use its own reverse shell to deploy what it is nowadays called an APT (yesterday backdoor). The attacker "won't see" his own machine from WCF as the DMZ provides the connection to the external world.
I have a half-dozen domains (with associated domain names), hosted locally on Windows/Apache and accessible to the wider internet. At the moment, the name servers are provided by my domain name register at extra cost. I would like to host a domain name service (on the same machine as is hosting the websites).
I have tried BIND without success, I was unable to configure it correctly. I was confused about zones and the syntax of configuration, as well as how to test if it is configured correctly!
Most guides seem directed at users who wish to replicate DNS entries for local caching, whereas I simply want to host a name server (locally) which directs users to my local machine, when they request any of the half-dozen websites I host.
Is there a simple application to host limited Domain Name Service this on Windows (Vista Business), or an obvious tutorial that I haven't found yet? Or was I on the right track with BIND and missing something?
Bind is probably the best choice. The guides you're referring to are talking about configuring a caching resolver. What you want is an authoritative name server. Bind can be a pain to configure because there are so many options, but it's probably worth persevering.
Depends what your budget is..
The DNS Server on Windows 2003 Server is pretty good and easy to configure.
There's a bunch of alternatives list here:
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
Simple DNS Plus could maybe do the trick for your case, but I haven't tried it.
Another option is maybe to use Bind and try to find a GUI for it, there's a few existing, usually web based, like webmin and such...
I'm investigating a little problem for my employer. My company runs a website under an SSL certificate for the domain www.domainone.net.nz (Yes, New Zealand)
However, there's been a high-level marketing decision to change our primary domain to www.domaintwo.co.nz.
So, easy, right? Buy a new SSL cert for www.domaintwo.co.nz and get it running on IIS. Easy.
However, we have a few WebServices published that need to be accessed over HTTPS - there's some systems in place out in the wild that are using https://www.domainone.net.nz/
I would like to run BOTH certs at the same time, and give our partners and clients that are using these WebServices a set timeframe (six months, say) to roll over to the new domain, before revoking the www.domainone.net.nz cert.
This is a bit fiddly to search for - I keep getting explanations of wildcard SSL domains, which wouldn't help in this particular case, as the central domain name has changed.
Is this possible under IIS? My asp.dll shows version 6.0.3790.4195
It's possible, if you have separate IP addresses for both sites, simply create two sites, one with each SSL certificate and point the directories for both sites to the same place.
But with a single website, no it's not possible
you should be able to do this as long as you have two different IP's one for each of the SSL Certs, you may have to set up two sites that point to the same location to get it working properly, but im not sure.