I’m trying to have a subdomain get the SSL lock because the current SSL cert on the subdomain is from the provider, which throws up warnings in certain browsers because it doesn’t match my domain. How can I get past the verification challenge if my server can’t host the challenge?
Maybe I'm reading too much into the question...
But you can't circumvent challenges - if so, then anyone could get any cert they asked for.
So you will have to meet the challenge requirements - somehow.
To that end, your best bet would be to use the DNS challenge method.
Which would require being able to enter TXT records into your domain name space.
Doing that would allow you to get pretty much any name you wanted from your domain - including a wildcard cert for your domain.
As for the "unauthorized/Invalid response from" error
If your running the certbot-auto from a system not found at the IP for that name (vip.andrewfranciosa.com), then that is what is normal and expected. You can only use webroot from the IP of the system in the cert name being requested.
Since is a Microsoft server running IIS, you could consider using one of the Windows ACME clents (such as win-acme).
You could also use Certbot from a different server using the certbot-dns-digitalocean plugin since your nameservers are hosted with them. This would have the dual benefit of allowing you to issue a wildcard.
I managed to get a wildcard cert issued for *.andrewfranciosa.com via txt records in the DNS. and certbot-auto certonly --manual -d *.andrewfranciosa.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
Now to activate the cert I just need to config the server to use it? Do I need to update the challenge dns every 30 days? ()
The cert is valid for 90 days, so anytime before that.
But there are ACME clients that can automate the DNS portion - provided your DNS provider is supported.
Thank you so much to everyone taking the time to help me.
I've configured that subdomain to use the SSL cert I generated, but when I go to https://vip.andrewfranciosa.com I get this:
vip.andrewfranciosa.com uses an invalid security certificate.
The certificate is only valid for the following names: *.pic-time.com, pic-time.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
So me having a wildcard for *.andrewfranciosa.com doesn't work if the host doesn't have me on their cert, because DNS is pointing that subdomain to their server?
Points to 40.76.59.117
If that system uses SNI (properly), you should be able to use your wildcard cert with your site there.
HTTP and HTTPS do show the same site - so at least that part is correct.
But they must be doing something wrong with the TLS cert assignments.
Sorry the hosted elsewhere threw me off...
If you have shell access, you should be able to find and fix the problem.
show: nginx -T
that may need some updating… it’s up to 1.14 now
show nginx -h
I get:
nginx -h
nginx version: nginx/1.14.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit
-t : test configuration and exit
-T : test configuration, dump it and exit
-q : suppress non-error messages during configuration testing
-s signal : send signal to a master process: stop, quit, reopen, reload
-p prefix : set prefix path (default: /etc/nginx/)
-c filename : set configuration file (default: /etc/nginx/nginx.conf)
-g directives : set global directives out of configuration file
Well after all this, I just asked the host if they plan to support https and they said it’s coming soon, but not there yet.
So I think this is resolved as my server can’t serve a certificate for a subdomain that is being pointed elsewhere via dns, that server has to host the cert for my domain, not the other way around.
nginx version: nginx/1.4.6 (Ubuntu)
Usage: nginx [-?hvVtq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit
-t : test configuration and exit
-q : suppress non-error messages during configuration testing
-s signal : send signal to a master process: stop, quit, reopen, reload
-p prefix : set prefix path (default: /usr/share/nginx/)
-c filename : set configuration file (default: /etc/nginx/nginx.conf)
-g directives : set global directives out of configuration file