Difference between revisions of "CertGetter"
Jump to navigation
Jump to search
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | '''<big><u>NOTICE: This is no longer valid! This machines function is being moved to the [[SBN - Web Server Notes|primary webserver]].</u></big>''' | ||
| + | |||
Proper SSL certificates can only be assigned to machines with Internet accessible FQDNs (Fully Qualified Domain Names). On an internal network, this causes all sorts of annoying problems since modern browsers actively oppose insecure connections (& even a self-signed certificate is considered insecure.) | Proper SSL certificates can only be assigned to machines with Internet accessible FQDNs (Fully Qualified Domain Names). On an internal network, this causes all sorts of annoying problems since modern browsers actively oppose insecure connections (& even a self-signed certificate is considered insecure.) | ||
| Line 30: | Line 32: | ||
*It is a good idea to [[CertGetter - Assign port 80|disconnect port 80]] from this machine when not in use. (especially if you have an actual webserver... | *It is a good idea to [[CertGetter - Assign port 80|disconnect port 80]] from this machine when not in use. (especially if you have an actual webserver... | ||
| − | == Interim Notes == | + | ==Interim Notes== |
| − | * To copy certs for a machine to your proxy server | + | *To copy certs for a machine to your proxy server (Replace '''Machine.Domain.TLD''' with the proper name for your machine...) (&, of course, '''user''' & '''webserver''' may need adjusting...) |
| − | ** First, make sure you can SSH into the proxy server from CertGetter | + | **First, make sure you can SSH into the proxy server from CertGetter |
| − | *** <code>ssh webserver</code> | + | ***<code>ssh webserver</code> |
| − | *** then exit when you've succeeded (this tells CertGetter how to get there...) | + | ***then exit when you've succeeded (this tells CertGetter how to get there...) |
| − | ** Then you can use '''scp''' to copy the certs. | + | **Then you can use '''scp''' to copy the certs. |
| − | *** <code>scp -r /etc/letsencrypt/live/Machine.Domain.TLD user@webserver:~</code> | + | ***<code>scp -r /etc/letsencrypt/live/Machine.Domain.TLD user@webserver:~</code> |
| − | ** Then ssh back into the proxy server & move the certs into their proper location | + | **Then ssh back into the proxy server & move the certs into their proper location |
| − | ** | + | ***<code>sudo mv Machine.Domain.TLD /etc/letsencrypt/live/</code> |
==Coming Soon...== | ==Coming Soon...== | ||
I am currently working on a script or 6 to make CertGetter automatically renew certs & push them to the appropriate machines. Watch this space. | I am currently working on a script or 6 to make CertGetter automatically renew certs & push them to the appropriate machines. Watch this space. | ||
Latest revision as of 01:14, 2 July 2020
NOTICE: This is no longer valid! This machines function is being moved to the primary webserver.
Proper SSL certificates can only be assigned to machines with Internet accessible FQDNs (Fully Qualified Domain Names). On an internal network, this causes all sorts of annoying problems since modern browsers actively oppose insecure connections (& even a self-signed certificate is considered insecure.)
If your internal network is set up to use your actual domain, This is a way to get certs for machines that are not accessible from the outside world.
These certs will expire & cannot be renewed automatically, but can be renewed using this same basic procedure. (simply running it again) You can also renew all of the certs this machine has obtained with sudo certbot renew
Setting Up
- Create a Baseline Server
- Install certbot
sudo apt-get install certbot
Usage
- Assign port 80 to this machine on your firewall
- Assign DNS for the name of the machine you're obtaining certs for
- Wait for the DNS entry to propagate
- You can repeatedly try
systemd-resolve machinename.yourdomain.netuntil it shows your outside address... - (Tho, you might need to do this from outside your local network.)
- You can repeatedly try
- Run certbot
sudo certbot certonly --standalone --dry-run- (Always test first with
--dry-run) - Then run it again if all is ok but without
--dry-run
- (Always test first with
- You will find the resulting certs in
/etc/letsencrypt/live/in a subfolder matching the machine name you gave certbot. - fullchain.pem is the certificate
- privkey.pem is the key
- Then simply copy fullchain.pem & privkey.pem (following the procedures for the OS involved) the cert to the machine in need.
- It is a good idea to disconnect port 80 from this machine when not in use. (especially if you have an actual webserver...
Interim Notes
- To copy certs for a machine to your proxy server (Replace Machine.Domain.TLD with the proper name for your machine...) (&, of course, user & webserver may need adjusting...)
- First, make sure you can SSH into the proxy server from CertGetter
ssh webserver- then exit when you've succeeded (this tells CertGetter how to get there...)
- Then you can use scp to copy the certs.
scp -r /etc/letsencrypt/live/Machine.Domain.TLD user@webserver:~
- Then ssh back into the proxy server & move the certs into their proper location
sudo mv Machine.Domain.TLD /etc/letsencrypt/live/
- First, make sure you can SSH into the proxy server from CertGetter
Coming Soon...
I am currently working on a script or 6 to make CertGetter automatically renew certs & push them to the appropriate machines. Watch this space.
