Answers: <p>Your question is very broad, but I'll try to answer it.</p>
  
  <ol>
  <li><p>You really need to read on what TLS/SSL is and how it works <strong>before</strong> you continue. You can find a bunch of questions in <a href="https://security.stackexchange.com/">security.stackexchange.com</a> that ask about this and many of them even link to RFCs where you can read the full detailed explanations of how it all works.</p></li>
  <li><p>To configure nginx to work with TLS/SSL certificate you can use <a href="https://www.digitalocean.com/community/tools/nginx" rel="nofollow noreferrer">https://www.digitalocean.com/community/tools/nginx</a> to generate the template. Just follow the guide and it should create a relatively secured vhost. If you would like to enhance the security even further - you can follow <a href="https://cipherli.st/" rel="nofollow noreferrer">cipherli.st</a>'s guide. They update it relatively often so the proposed settings are usually up-to-date.</p></li>
  <li><p>What makes a certificate "valid" or "invalid"? It's the <code>Certificate Authority</code>. It is possible to create a private CA certificate and use it to sign a <code>Certificate Signing Request</code> (or <code>CSR</code>). The <code>CSR</code> can then be signed by the <code>CA</code> and returned to whoever needs it (in this case the Nginx server). There are multiple tutorials for this available online and you can use <code>easy-rsa</code> to do the heavy lifting. However, the down side of doing it this way is that you need to go over all machines in the network and install the <code>CA</code> in browsers and all necessary keystores. Otherwise those machine will treat the site's certificates as "untrusted" because it will be coming from an unknown <code>Certificate Authority</code>. In some cases you can also create a <a href="https://www.ssls.com/knowledgebase/how-to-install-an-ssl-certificate-on-a-nginx-server/" rel="nofollow noreferrer"><code>Certificate Bundle</code></a> for nginx.</p>
  
  <p><a href="https://i.sstatic.net/egvLW.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/egvLW.png" alt="CA"></a></p></li>
  <li><p>If you had an ingress available you could have used <code>LetsEncrypt</code> to automatically issue certificates and skip complicating your setup by having <code>CA</code> and issuing certificates on your own.</p></li>
  </ol>
  
  <p>Note: Image has been borrowed from ssl.com.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-24T02:44:32.387Z
Answers: 2019-12-24T09:46:31.803Z
Answers: 2019-12-24T09:46:31.803Z
Answers: tftd
Body: <p>I'm running Jenkins on an Ubuntu machine bare metal, and as I'm only experimenting and learning how the ops of it all works, I now want to learn how to enable https (with a nominally valid certificate obviously). I want to talk to a git instance and other tools and keep the automation tools secure. I believe the easiest is to use a reverse proxy, NGINX. Which I assume just acts like a forwarder; this is where I get stuck as a newbie.</p>
  
  <p>I am unable to set up or follow the nginx initial steps to obtain a certificate, because the key generation tool (keytool) just does nothing when I give it a URL. It keeps saying my computer's FQDN is not valid.</p>
  
  <p>I guess that's because my ubuntu machine is behind a NAT. I am guessing it's not realistic to create a trusted server on a private LAN which only has egress, but no ingress? Do I really need a real domain? I have one, but since this is work related, I'm loathe to create any kind of link-up between work and play. This feels a little workaround hacky-like, so keen for alternatives to what looks like an overkill configuration. For an internal experimental Jenkins setup, is there a 3 step process that a beginner who knows very little about keys can follow?</p>
  
Tags: <jenkins>
Title: nginx for dummies? How to enable Jenkins over https
UserDisplayName: Conrad B
ThreadText: # nginx for dummies? How to enable Jenkins over https
  
  (Asked by: username_0 on 2019-12-23)
  
  I'm running Jenkins on an Ubuntu machine bare metal, and as I'm only experimenting and learning how the ops of it all works, I now want to learn how to enable https (with a nominally valid certificate obviously). I want to talk to a git instance and other tools and keep the automation tools secure. I believe the easiest is to use a reverse proxy, NGINX. Which I assume just acts like a forwarder; this is where I get stuck as a newbie.
  
  I am unable to set up or follow the nginx initial steps to obtain a certificate, because the key generation tool (keytool) just does nothing when I give it a URL. It keeps saying my computer's FQDN is not valid.
  
  I guess that's because my ubuntu machine is behind a NAT. I am guessing it's not realistic to create a trusted server on a private LAN which only has egress, but no ingress? Do I really need a real domain? I have one, but since this is work related, I'm loathe to create any kind of link-up between work and play. This feels a little workaround hacky-like, so keen for alternatives to what looks like an overkill configuration. For an internal experimental Jenkins setup, is there a 3 step process that a beginner who knows very little about keys can follow?
  
  **Tags:** jenkins
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-12-24. Score: 3
  
  Your question is very broad, but I'll try to answer it.
  
  1. You really need to read on what TLS/SSL is and how it works **before** you continue. You can find a bunch of questions in [security.stackexchange.com](https://security.stackexchange.com/) that ask about this and many of them even link to RFCs where you can read the full detailed explanations of how it all works.
  2. To configure nginx to work with TLS/SSL certificate you can use <https://www.digitalocean.com/community/tools/nginx> to generate the template. Just follow the guide and it should create a relatively secured vhost. If you would like to enhance the security even further - you can follow [cipherli.st](https://cipherli.st/)'s guide. They update it relatively often so the proposed settings are usually up-to-date.
  3. What makes a certificate "valid" or "invalid"? It's the `Certificate Authority`. It is possible to create a private CA certificate and use it to sign a `Certificate Signing Request` (or `CSR`). The `CSR` can then be signed by the `CA` and returned to whoever needs it (in this case the Nginx server). There are multiple tutorials for this available online and you can use `easy-rsa` to do the heavy lifting. However, the down side of doing it this way is that you need to go over all machines in the network and install the `CA` in browsers and all necessary keystores. Otherwise those machine will treat the site's certificates as "untrusted" because it will be coming from an unknown `Certificate Authority`. In some cases you can also create a [`Certificate Bundle`](https://www.ssls.com/knowledgebase/how-to-install-an-ssl-certificate-on-a-nginx-server/) for nginx.
  
     [![CA](https://i.sstatic.net/egvLW.png)](https://i.sstatic.net/egvLW.png)
  4. If you had an ingress available you could have used `LetsEncrypt` to automatically issue certificates and skip complicating your setup by having `CA` and issuing certificates on your own.
  
  Note: Image has been borrowed from ssl.com.
  
  
  ---
  
  