I'm sure some people would find this useful but forgive me if I'm not ready to hand away my security to some unknown third party company. I don't know the first thing about CAs but Let's Encrypt really isn't that difficult to understand.
There's a scale beyond which the real challenge isn't issuing a certificate.
I see organisations with thousands of SSL certificates, and their struggle is real. Even reputable companies with huge teams have their certificates expire or served badly. Some serve expired certificates for years!
Plus, enterprise alternatives are extremely costly and rigid.
* If you want an SSL certificate for, say, your printer
* And you don’t want to expose your printer’s port 80 to the public internet because you’re not stupid
* And you don’t want to put your DNS credentials onto your printer either, because again, you’re not stupid
* And you don’t want to pay for a certificate with a longer validity, because it’s a home printer, so you’re stitch with monthly cert rotations
* And you’ve embraced the reality that one can delegate SSL not just to CAs, but also to other third parties. Usually the likes of AWS & cloudflare - but why stop there?
I think it's more a matter of scale. If you need SSL certificates for hundreds of appliances and you want to manage it, rather than hack it, that's the product you need.
Most people find the user experience of self-signed certificates much worse. The developer experience for local issuance isn't great, although mkcert does a really great job of smoothing the parts that can be smoothed[1].
I started but haven't yet completed a project to use mkcert on a home server, and get all devices in the house to trust it as a CA for things such as printers and "internal tools" for my family such as Jellyfin, etc.
This would probably be easier if I was organized enough to use at least minimal MDM features on the family's devices though, so I haven't actually completed this project yet.
Well yes, you've just hit on why this is a rather niche product.
You get a handful of somewhat questionable benefits. If for some reason your guests are visiting your printer's administration page, they won't have to click through a scary warning page. If someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
But the main reason is some homelab enthusiasts are like bodybuilders at the gym - taking on tasks that seem Sisyphean to outsiders, for fun and to build their strength.
> someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
If they're persistently stealing traffic from my network then the printers administrative password is the least worrisome part.
> homelab enthusiasts are like bodybuilders at the gym
Self obsessed to the point of absurdity? There was a vulnerability a few years ago where you could embed an HP Printer Firmware update into the middle of a print file by taking advantage of some insane JCL commands. You can also embed JCL commands directly into a word document.
So these researchers created a word document that when printed updates your printers firmware with a hacked version allowing an advanced persistent threat to live inside your printer.
If your printer has no anti virus or no intrusion detection then putting an SSL certificate on there is entirely pointless.
If you're already thinking in the IPv6 mode of thought — where NAT / network-local addresses are irrelevant/obsolete, as long as there's a stateful firewall somewhere in front of your LAN devices, to treat all LAN devices as default-closed to incoming packets from outside the LAN's IPv6 network prefix...
...then (at least in theory!) there's no reason to not also give every one of those devices, with their public-routable IPv6 addresses, a stable public-rooted name — i.e. a DNS FQDN.
Mind you, none of the infrastructure to make this work exists.
For example, while DDNS exists, it really only exists to assign your gateway router itself a name — with the expectation being that you're using NAT, and then having your router port-forward any interior services to masquerade them as being services of the router.
A theoretical "DDNSv6", meanwhile, would instead expose your entire LAN as AAAA records under your DDNS suffix — much like how e.g. `tailscale share` exposes devices as device.yournetwork.ts.net. But using plain public-routed IPv6, rather than proprietary overlay routing.
The problem with this being that neither routers nor IoT devices have any way to assign DNS-like names to devices on your network. So where would these device names come from? (If it were me, I'd have the router observe mDNS announcements from these devices, and then suffix-replace `.local` in the mDNS name with the configured DDNS suffix to build AAAA records. But even then, some devices don't even do mDNS!)
And then, even if you do that, there's still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable, and for physical access to the network segment to be the sum total of its security mechanism.) To work around this, you'd need your gateway router to do L7 IPv6 routing (imagine if your router worked like Cloudflare DNS, where you could "orange cloud" your LAN devices) so that the router itself could 1. force itself as the default route for the device, even for LAN-to-LAN packets; and then 2. terminate the TLS connection if the device is being spoken to on port 443; but just act as a dumb passthrough otherwise.
> still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable
one minor correction: modern (even 5-10 year old) printers do support TLS -- and they even try to push you to use it when they only have the built-in self-signed certificate. I've seen screens encouraging me to "click trust" etc. which seems idiotic to train anyone to do when the stakes of letting them admin the printer, over the LAN, over HTTP are so low. I'm so sure that a random rogue IOT device on my LAN is listening to that printer administration traffic, real high-value stuff there. Mind you that this is unrelated to whether a rogue LAN actor could sniff the actual documents being printed, since I don't think computers are typically set up to print with IPP over TLS, but use unencrypted protocols instead.
Anyway, with my HP printer, you can upload a cert and key file and that way it'll use a cert of your choice.
We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.
EFF has a great write up of the 'validation domain CNAME' approach this uses. It's great to see another entry in this space. As great as ACME is, there are still sharp edges we can improve with tricks like this.
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext, yet plaintext has to get used because of some element of certificates expiring needs renwal. Even bad or easy to crack encryption is better than plain text, yet I totally get why many scenarios end up using plain text (i’m talking in an internal or home lab type set up). I understand why public facing certificates need renewals
You could see expiring certificates as a chance to examine your security regularly: protocols and ciphers change, bugs are fixed, vulnerabilities are discovered and fixed.
Setup and forget is never good for security. From what I see with sslboard.com (I'm the founder), all hosts serving old expired certificates also have bad TLS versions and ciphers (RC4, DES) and vulnerabilities.
Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate.
This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.
I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext.
I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?
For an internal use case, nothing's stopping you from setting up your own CA, creating certificates that don't expire for 100 years, and telling your clients to trust them. It just takes a couple of OpenSSL commands which, while slightly complicated if you don't know what you're doing, can be easily automated with a shell script.
The browser limits on maximum certificate lifetimes only apply to the public web PKI, not to CAs that you configure yourself.
You don't even need to remember any OpenSSL commands. I manage all of my home certificates using XCA GUI.
When creating your CA certificate you can hop into the Advanced tab and add the following line to constrain it to specific domains. This eliminates the risk of your likely-poorly-secured CA being abused to MITM all of your communications:
This will only allow CA to sign certificates for *.home.internal. I think browser support for nameConstraints is pretty good these days but some clients might not be compatible and you can always install a CA certificate without this extension on devices that don't support it.
I only recently got into Caddy after using Apache and later Nginx for decades, and it's almost disappointing how little configuration it needs. It's very refreshing that we finally have a web server that needs hardly any fiddling with b/c it has nicely sane and comprehensive defaults.
> We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
That makes no sense whatsoever.
If you have an ACME account key for my domain, of course you can use it to impersonate my domain. You just need to create another certificate. (Which I could detect, but if I know how to do that, I'm probably not going to need your service anyway.)
We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/, but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.
Sorry, not trying to obfuscate anything, hopefully this clarifies: users trust us to hold their ACME account key and we only ask for DNS records prefixed with `_acme-challenge.` to be CNAME delegated.
With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.
Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates.
I'm sorry. But do you really need to re-invent the wheel yet again ?
Go to the Let's Encrypt website, there is a whole page of client implementations[1].
What makes yours better than, for example, `lego` or `caddy` or `step` ?
All of which are easy to use, come with sensible defaults and do not provide you with "innumerable ways to shoot yourself in the foot".
And for people who really can't use Let's Encrypt because "its difficult", there are still all the old-school, well-established, commercial CA's out there who will hold your hand in return for a few dollars.
I haven't fully looked into it, but it seems to me that this is basically a hosted version of Acme-dns (https://github.com/joohoi/acme-dns)
The point of acme-dns is for people who 1) need to use DNS validation because they don't have an externally accessible web server or need a wildcard cert and 2) either use DNS providers that don't provide API support or whose API support has not been integrated into their tool of choice like cert-manager or certbot.
I have had to use ACME-DNS for that reason, and I don't think it is a horrible business to try to offer that as a service. I don't think I would use it (since acme-dns isn't that hard to set up and I am familiar with it), but I could imagine other people might want to.
We don't think of it as reinventing the wheel since it works with all existing RFC compliant ACME clients without needing a plugin. You can use lego, caddy, certbot, cert-manager, or whichever ACME client you prefer.
ACME is great and it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.
I'm a bit confused the benefits? Caddy already makes Let's encrypt incredibly easy. I use the CloudFlare DNS provider, so don't even need to expose port 80 for http verification.
I am pretty sure the main purpose is for people who use a DNS provider that does not have integrated support with certbot or cert-manager (basically this is a hosted acme dns (https://github.com/joohoi/acme-dns)
Every single SAAS product faces this criticism. You can always do it yourself, but if some people don't want to, I don't think it is bad to offer a hosted version.
I'm sure some people would find this useful but forgive me if I'm not ready to hand away my security to some unknown third party company. I don't know the first thing about CAs but Let's Encrypt really isn't that difficult to understand.
There's a scale beyond which the real challenge isn't issuing a certificate.
I see organisations with thousands of SSL certificates, and their struggle is real. Even reputable companies with huge teams have their certificates expire or served badly. Some serve expired certificates for years!
Plus, enterprise alternatives are extremely costly and rigid.
All the more reason to automate renewing of certificates.
I believe the intent here is:
* If you want an SSL certificate for, say, your printer
* And you don’t want to expose your printer’s port 80 to the public internet because you’re not stupid
* And you don’t want to put your DNS credentials onto your printer either, because again, you’re not stupid
* And you don’t want to pay for a certificate with a longer validity, because it’s a home printer, so you’re stitch with monthly cert rotations
* And you’ve embraced the reality that one can delegate SSL not just to CAs, but also to other third parties. Usually the likes of AWS & cloudflare - but why stop there?
Then this product is what you need!
I think it's more a matter of scale. If you need SSL certificates for hundreds of appliances and you want to manage it, rather than hack it, that's the product you need.
Why not sign it yourself?
Most people find the user experience of self-signed certificates much worse. The developer experience for local issuance isn't great, although mkcert does a really great job of smoothing the parts that can be smoothed[1].
[1]: https://github.com/FiloSottile/mkcert
I started but haven't yet completed a project to use mkcert on a home server, and get all devices in the house to trust it as a CA for things such as printers and "internal tools" for my family such as Jellyfin, etc.
This would probably be easier if I was organized enough to use at least minimal MDM features on the family's devices though, so I haven't actually completed this project yet.
Are there any printers that actually run acme where this is even a consideration?
> * If you want an SSL certificate for, say, your printer
Ummmm why does my printer need a certificate?
Well yes, you've just hit on why this is a rather niche product.
You get a handful of somewhat questionable benefits. If for some reason your guests are visiting your printer's administration page, they won't have to click through a scary warning page. If someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
But the main reason is some homelab enthusiasts are like bodybuilders at the gym - taking on tasks that seem Sisyphean to outsiders, for fun and to build their strength.
> someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
If they're persistently stealing traffic from my network then the printers administrative password is the least worrisome part.
> homelab enthusiasts are like bodybuilders at the gym
Self obsessed to the point of absurdity? There was a vulnerability a few years ago where you could embed an HP Printer Firmware update into the middle of a print file by taking advantage of some insane JCL commands. You can also embed JCL commands directly into a word document.
So these researchers created a word document that when printed updates your printers firmware with a hacked version allowing an advanced persistent threat to live inside your printer.
If your printer has no anti virus or no intrusion detection then putting an SSL certificate on there is entirely pointless.
If you can't trust your network, you'll want encryption, regardless of devices on it.
if you can't trust your network, everything needs to be public internet level hardened anyway, so why not just directly use letsencrypt?
Because you don't want to expose your printer to the public Internet?
Then you need to make your network trustworthy first.
Why?
If you're already thinking in the IPv6 mode of thought — where NAT / network-local addresses are irrelevant/obsolete, as long as there's a stateful firewall somewhere in front of your LAN devices, to treat all LAN devices as default-closed to incoming packets from outside the LAN's IPv6 network prefix...
...then (at least in theory!) there's no reason to not also give every one of those devices, with their public-routable IPv6 addresses, a stable public-rooted name — i.e. a DNS FQDN.
Mind you, none of the infrastructure to make this work exists.
For example, while DDNS exists, it really only exists to assign your gateway router itself a name — with the expectation being that you're using NAT, and then having your router port-forward any interior services to masquerade them as being services of the router.
A theoretical "DDNSv6", meanwhile, would instead expose your entire LAN as AAAA records under your DDNS suffix — much like how e.g. `tailscale share` exposes devices as device.yournetwork.ts.net. But using plain public-routed IPv6, rather than proprietary overlay routing.
The problem with this being that neither routers nor IoT devices have any way to assign DNS-like names to devices on your network. So where would these device names come from? (If it were me, I'd have the router observe mDNS announcements from these devices, and then suffix-replace `.local` in the mDNS name with the configured DDNS suffix to build AAAA records. But even then, some devices don't even do mDNS!)
And then, even if you do that, there's still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable, and for physical access to the network segment to be the sum total of its security mechanism.) To work around this, you'd need your gateway router to do L7 IPv6 routing (imagine if your router worked like Cloudflare DNS, where you could "orange cloud" your LAN devices) so that the router itself could 1. force itself as the default route for the device, even for LAN-to-LAN packets; and then 2. terminate the TLS connection if the device is being spoken to on port 443; but just act as a dumb passthrough otherwise.
> still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable
one minor correction: modern (even 5-10 year old) printers do support TLS -- and they even try to push you to use it when they only have the built-in self-signed certificate. I've seen screens encouraging me to "click trust" etc. which seems idiotic to train anyone to do when the stakes of letting them admin the printer, over the LAN, over HTTP are so low. I'm so sure that a random rogue IOT device on my LAN is listening to that printer administration traffic, real high-value stuff there. Mind you that this is unrelated to whether a rogue LAN actor could sniff the actual documents being printed, since I don't think computers are typically set up to print with IPP over TLS, but use unencrypted protocols instead.
Anyway, with my HP printer, you can upload a cert and key file and that way it'll use a cert of your choice.
We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.
EFF has a great write up of the 'validation domain CNAME' approach this uses. It's great to see another entry in this space. As great as ACME is, there are still sharp edges we can improve with tricks like this.
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext, yet plaintext has to get used because of some element of certificates expiring needs renwal. Even bad or easy to crack encryption is better than plain text, yet I totally get why many scenarios end up using plain text (i’m talking in an internal or home lab type set up). I understand why public facing certificates need renewals
You could see expiring certificates as a chance to examine your security regularly: protocols and ciphers change, bugs are fixed, vulnerabilities are discovered and fixed.
Setup and forget is never good for security. From what I see with sslboard.com (I'm the founder), all hosts serving old expired certificates also have bad TLS versions and ciphers (RC4, DES) and vulnerabilities.
> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext
Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate.
This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.
I wrote much more here: https://alexsci.com/blog/is-email-confidential-in-transit-ye...
I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext.
I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?
For an internal use case, nothing's stopping you from setting up your own CA, creating certificates that don't expire for 100 years, and telling your clients to trust them. It just takes a couple of OpenSSL commands which, while slightly complicated if you don't know what you're doing, can be easily automated with a shell script.
The browser limits on maximum certificate lifetimes only apply to the public web PKI, not to CAs that you configure yourself.
You don't even need to remember any OpenSSL commands. I manage all of my home certificates using XCA GUI.
When creating your CA certificate you can hop into the Advanced tab and add the following line to constrain it to specific domains. This eliminates the risk of your likely-poorly-secured CA being abused to MITM all of your communications:
This will only allow CA to sign certificates for *.home.internal. I think browser support for nameConstraints is pretty good these days but some clients might not be compatible and you can always install a CA certificate without this extension on devices that don't support it.Modern web browsers have started distrusting certificates over a certain lifetime. So annoying!
Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you:
[0] https://caddyserver.comI only recently got into Caddy after using Apache and later Nginx for decades, and it's almost disappointing how little configuration it needs. It's very refreshing that we finally have a web server that needs hardly any fiddling with b/c it has nicely sane and comprehensive defaults.
Once you go Caddy, you never go back to Nginx and Apache.
+1 to Caddy - Another happy user that stopped caring about managing SSL certs 3 years ago.
Does this means that you have the ability to
a) impersonate the identities of your users and b) decrypt the SSL traffic of your users
?
It does not.
Anchor never see sees your private keys for certificates.
We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
We have a more technical overview of how this works in our docs: https://anchor.dev/docs/public-certs/acme-relay
> We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
That makes no sense whatsoever. If you have an ACME account key for my domain, of course you can use it to impersonate my domain. You just need to create another certificate. (Which I could detect, but if I know how to do that, I'm probably not going to need your service anyway.)
If users delegate their DNS to you, what's stopping you issuing a certificate to yourself for their site?
We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/, but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.
Right, but if you want people to trust you, you need to be open about what people are trusting you with. Your original answer seemed obfuscatory.
Sorry, not trying to obfuscate anything, hopefully this clarifies: users trust us to hold their ACME account key and we only ask for DNS records prefixed with `_acme-challenge.` to be CNAME delegated.
With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.
> we couldn't impersonate them because we don't control the rest of their DNS.
If that were true, nobody would need signed certificates in the first place.
Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates.
https://crt.sh for point in time checks, https://sslboard.com for comprehensive oversight (disclosure: I'm the founder)
Your site doesn't work. The right arrow button is always disabled
sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
iOS safari
Oh dear.
I'm sorry. But do you really need to re-invent the wheel yet again ?
Go to the Let's Encrypt website, there is a whole page of client implementations[1].
What makes yours better than, for example, `lego` or `caddy` or `step` ?
All of which are easy to use, come with sensible defaults and do not provide you with "innumerable ways to shoot yourself in the foot".
And for people who really can't use Let's Encrypt because "its difficult", there are still all the old-school, well-established, commercial CA's out there who will hold your hand in return for a few dollars.
[1] https://letsencrypt.org/docs/client-options/
I haven't fully looked into it, but it seems to me that this is basically a hosted version of Acme-dns (https://github.com/joohoi/acme-dns)
The point of acme-dns is for people who 1) need to use DNS validation because they don't have an externally accessible web server or need a wildcard cert and 2) either use DNS providers that don't provide API support or whose API support has not been integrated into their tool of choice like cert-manager or certbot.
I have had to use ACME-DNS for that reason, and I don't think it is a horrible business to try to offer that as a service. I don't think I would use it (since acme-dns isn't that hard to set up and I am familiar with it), but I could imagine other people might want to.
We don't think of it as reinventing the wheel since it works with all existing RFC compliant ACME clients without needing a plugin. You can use lego, caddy, certbot, cert-manager, or whichever ACME client you prefer.
ACME is great and it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.
I'm a bit confused the benefits? Caddy already makes Let's encrypt incredibly easy. I use the CloudFlare DNS provider, so don't even need to expose port 80 for http verification.
I am pretty sure the main purpose is for people who use a DNS provider that does not have integrated support with certbot or cert-manager (basically this is a hosted acme dns (https://github.com/joohoi/acme-dns)
for everyone willing to put a tiny amount of effort in, you can just:
1. Install acme-dns somewhere
2. Point part of your domain to that
3. Use lego or caddy or whatever to get certs using dns-01
No need to pay some dude who can then forge certs for your domain.
Every single SAAS product faces this criticism. You can always do it yourself, but if some people don't want to, I don't think it is bad to offer a hosted version.