Why not generate a new certificate?

Reply to this note

Please Login to reply.

Discussion

the nsite server is using a *.nsite.lol, nsite.lol cert and I don't know how to make it switch certs based on the domain

this is a little thing i built that can do it https://github.com/mleku/realy/tree/dev/cmd/lerproxy

it also lets you set certs for your own ... actually, i'm not sure if it can do more than one for your own SSL cert but it can do many for others using letsencrypt

oh yeah, it should be able to do multiple of your own certs if you need that, according to the config code i see here

it also does nip-05 and golang vanity redirects with a redirector that lets you set up one like https://realy.lol that will also redirect a web browser to the repo as well as tell Go to look there for dependencies

Is the original domain name registered with that original hosting provider? In that case I see you would not be able to control the DNS records. Otherwise I think you should be able to set the original domain name to the new IP address. There might still be a way but might be troublesome. One of the use cases for domain names is the ability to point an existing name to a different host. I was curious because I was thinking about how DNS might be a weak point for nostr. DNS could be superfluous and therefore an unnecessary risk if the same thing that you experienced is common: losing access to the domain name controls when losing access to hosting. DNS, as Moxie pointed out a while ago, is "distributed" in the sense that the data are distributed, but the trust is centralized. DNS takedowns are a common censorship technique. Nostr might be better off using IP addresses directly, but that leads back to HTTPS/TLS and trying to get a TLS certificate where the common name is the IP address. Let's Encrypt, for example, won't issue a certificate for a non-DNS name such as an IP address.