srvrco / getssl

obtain free SSL certificates from letsencrypt ACME server Suitable for automating the process on remote servers.
GNU General Public License v3.0
2.08k stars 374 forks source link

Doesn't need nslookup #221

Closed rdebath closed 7 years ago

rdebath commented 7 years ago

If I'm using the http-01 protocol the use of nslookup is a simple sanity check (does the domain exist).

Unfortunately my webhost uses FreeBSD and doesn't have this port installed, they do have a lot of other stuff installed so I suspect they might be happy to add it, but first...

Can you add an option that makes the http-01 sanity check use the host command instead, or just disables the check.

If I comment out the sanity check I can successfully create an account, get a certificate and install it completely automatically.

[tvtcloudsite /home/private/getssl]$ host -t AAAA www.google.com
www.google.com has IPv6 address 2607:f8b0:4007:800::2004
[tvtcloudsite /home/private/getssl]$ host -t A www.google.com
www.google.com has address 172.217.4.132
[tvtcloudsite /home/private/getssl]$ host -t A not.google.com
Host not.google.com not found: 3(NXDOMAIN)
[tvtcloudsite /home/private/getssl]$ host -t AAAA not.google.com
Host not.google.com not found: 3(NXDOMAIN)
[tvtcloudsite /home/private/getssl]$ nslookup
-bash: nslookup: command not found
[tvtcloudsite /home/private/getssl]$
srvrco commented 7 years ago

Thanks. I'll have a look at modifying things. Currently it checks at the beginning of everything it may need, rather than when it's needed.

jbeima commented 7 years ago

Would you mind if I asked a quick question?

For getssl-enhanced I was already looking at possible options for alternate applications when one is not installed. It is on my list of things.

However both nslookup and host come from the same source bind-utils. You would not normally by default have one without the other.

Could your ISP have removed nslookup but left host in place?

On Jan 11, 2017, at 2:36 AM, rdebath notifications@github.com wrote:

If I'm using the http-01 protocol the use of nslookup is a simple sanity check (does the domain exist).

Unfortunately my webhost uses FreeBSD and doesn't have this port installed, they do have a lot of other stuff installed so I suspect they might be happy to add it, but first...

Can you add an option that makes the http-01 sanity check use the host command instead, or just disables the check.

If I comment out the sanity check I can successfully create an account, get a certificate and install it completely automatically.

[tvtcloudsite /home/private/getssl]$ host -t AAAA www.google.com www.google.com has IPv6 address 2607:f8b0:4007:800::2004 [tvtcloudsite /home/private/getssl]$ host -t A www.google.com www.google.com has address 172.217.4.132 [tvtcloudsite /home/private/getssl]$ host -t A not.google.com Host not.google.com not found: 3(NXDOMAIN) [tvtcloudsite /home/private/getssl]$ host -t AAAA not.google.com Host not.google.com not found: 3(NXDOMAIN) [tvtcloudsite /home/private/getssl]$ nslookup -bash: nslookup: command not found [tvtcloudsite /home/private/getssl]$ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

rdebath commented 7 years ago

It seems it wasn't the ISP, but FreeBSD itself ...

https://www.freebsd.org/releases/10.0R/relnotes.html#userland https://svnweb.freebsd.org/base?view=revision&revision=255949

From the release notes ...

BIND has been removed from the base system. unbound(8), which is maintained by NLnet Labs, has been imported to support local DNS resolution functionality with DNSSEC. Note that it is not a replacement of BIND and the latest versions of BIND is still available in the Ports Collection. With this change, nslookup and dig are no longer a part of the base system. Users should instead use host(1) and drill(1) Alternatively, nslookup and dig can be obtained by installing dns/bind-tools port. [r255949]

As to why nslookup went with bind, that question doesn't seem to have a good answer.

jbeima commented 7 years ago

It might actually. :)

Since there is obviously more than one DNS server/daemon.

Not everyone might carry a version of nslookup, some may only have host.

I was going to ask you that next, once you had responded.

Do you have anyway of finding out which DNS server they are running?

John Beima jbeima@getsslproject.org

On Jan 11, 2017, at 11:06 AM, rdebath notifications@github.com wrote:

It seems it wasn't the ISP, but FreeBSD itself ...

https://www.freebsd.org/releases/10.0R/relnotes.html#userland https://svnweb.freebsd.org/base?view=revision&revision=255949

From the release notes ...

BIND has been removed from the base system. unbound(8), which is maintained by NLnet Labs, has been imported to support local DNS resolution functionality with DNSSEC. Note that it is not a replacement of BIND and the latest versions of BIND is still available in the Ports Collection. With this change, nslookup and dig are no longer a part of the base system. Users should instead use host(1) and drill(1) Alternatively, nslookup and dig can be obtained by installing dns/bind-tools port. [r255949]

As to why nslookup went with bind, that question doesn't seem to have a good answer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

rdebath commented 7 years ago

I suspect the visible issue with nslookup was that it used a different resolver library to BIND itself so was seen as a poor program for debugging BIND. Then nobody (at FreeBSD) was really interested in making an independent compile of it even if it's possible to do that without the BIND libraries.

The "good" program for BIND is dig, and they provided the drill replacement for that (It sort of works like dig, but not).

As for "NSFN", the shell environment I get is pretty locked down from the "system tools" point of view, but looking at /etc/resolv.conf makes me suspect they don't have a resolver process on the same machine. However, the /usr/sbin/unbound program is installed so it looks like a pretty standard install at that point.

jbeima commented 7 years ago

THANK YOU! This has been helpful!

John Beima jbeima@getsslproject.org

On Jan 11, 2017, at 11:37 AM, rdebath notifications@github.com wrote:

I suspect the visible issue with nslookup was that it used a different resolver library to BIND itself so was seen as a poor program for debugging BIND. Then nobody (at FreeBSD) was really interested in making an independent compile of it even if it's possible to do that without the BIND libraries.

The "good" program for BIND is dig, and they provided the drill replacement for that (It sort of works like dig, but not).

As for "NSFN", the shell environment I get is pretty locked down from the "system tools" point of view, but looking at /etc/resolv.conf makes me suspect they don't have a resolver process on the same machine. However, the /usr/sbin/unbound program is installed so it looks like a pretty standard install at that point.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

srvrco commented 7 years ago

@rdebath I've added a new branch - https://github.com/srvrco/getssl/tree/drill which will use drill instead of nslookup if nslookup isn't available and drill is.

Please can you test it ( it worked fine on my systems). If you want a direct link to the source code it's available at - https://raw.githubusercontent.com/srvrco/getssl/drill/getssl

I will test on a few more systems before merging the branch.

rdebath commented 7 years ago

Looks good, I did a full sign-up and key create with the default top config and this site config. Did a forced update then a forced update for a real certificate.

# CA="https://acme-v01.api.letsencrypt.org"
ACL=('/home/public/.well-known/acme-challenge')
DOMAIN_PEM_LOCATION="/home/private/ssl-cert.pem"
RELOAD_CMD="reload_nfsn"
reload_nfsn() {
        nfsn -i set-tls < "$DOMAIN_PEM_LOCATION"
}
RENEW_ALLOW="30"

You might want to fix that; I forgot to put a real email address in and it didn't complain. So obviously it's not required but a warning might be nice.

[tvtcloudsite /home/private]$ ./getssl www.tvtcloud.co.uk
creating account key /home/private//.getssl/account.key
creating domain key - /home/private//.getssl/account.key
Generating RSA private key, 4096 bit long modulus
.............................................................++
..............................................++
e is 65537 (0x10001)
creating domain key - /home/private//.getssl/www.tvtcloud.co.uk/www.tvtcloud.co.uk.key
Generating RSA private key, 4096 bit long modulus
..................................................................................................................++
.............................................................................++
e is 65537 (0x10001)
creating domain csr - /home/private//.getssl/www.tvtcloud.co.uk/www.tvtcloud.co.uk.csr
Registering account
Registered
Verify each domain
Verifying www.tvtcloud.co.uk
copying challenge token to /home/public/.well-known/acme-challenge/YKyvtK0cXPJYOYxrREgfzqUDn5OV_KJiSf__icllSFY
Pending
Verified www.tvtcloud.co.uk
Verification completed, obtaining certificate.
Certificate saved in /home/private//.getssl/www.tvtcloud.co.uk/www.tvtcloud.co.uk.crt
The intermediate CA cert is in /home/private//.getssl/www.tvtcloud.co.uk/chain.crt
copying full key, cert and chain pem to /home/private/ssl-cert.pem
reloading SSL services
INFO: Enabling TLS for www.tvtcloud.co.uk
e4: OK (www.tvtcloud.co.uk)
e3: OK (www.tvtcloud.co.uk)
e5: OK (www.tvtcloud.co.uk)
e6: OK (www.tvtcloud.co.uk)
OK: Setup was fully confirmed.
www.tvtcloud.co.uk - certificate installed OK on server
certificate obtained for www.tvtcloud.co.uk
[tvtcloudsite /home/private]$
srvrco commented 7 years ago

Many Thanks.

Good point, it's probably worth a comment - it's not a requirement to actually have an email.

srvrco commented 7 years ago

I've added this to the master branch, and also included dig and host as alternatives.