Ok, I am thinking maybe we would just do the wildcard certs via another CA then. Given how the system (“FreeToastHost” or FTH for short) is structured, using wildcard certs for category #1 and category #2 domains/subdomains is the least pain approach. We control those domains, we have access to the server for those, and the server code (that I update) handles creating the subdomains automatically, etc.
[quote=“schoen, post:2, topic:31092, full:true”]
The rate limits probably wouldn’t affect the separate domains in #3, because most of the limits relate to certificates requested to be issued under the same registered domain. If you have a large number of distinct registered domains, you can get a large number of certificates without hitting a limit, although if you’re willing to combine names in large SAN certs, you could cover everything in #3 with just 10 different certs![/quote]
For category #3 domains, based on your comments, I still think LE may be a good approach. However, for those domains, at this time there is really not a viable way to grant access to the server for storing certs (no code for it, no folders allocated for it, no controlled UI for it, etc.), but the clubs that get those domains do have access to their DNS records, so I am thinking that could be the approach. For category #3 domains, there is no subdomain mechanism supported by the system.
For category #3 domains, we do also know the domain names in our db… clubs have to put them there also to allow us to look up their content in the db by domain name. Because of this, I am wondering if we could use that call the client software to get them a cert… Not sure how we prove control of the domain via server code–we could make an automated request for a cert on their behalf, but not sure about the validation. If would be great if we could them email them the cert with instructions in the email to install it in their DNS records… Does this sound like a viable approach?