enable https on private network





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







1















My company is creating presentation software. When in use, presenters sign on through an HTTPS enabled web site to send text, documents, authentication tokens, etc.



My question is this: How do I enable HTTPS communication when:




  1. There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.

  2. The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)

  3. No manual steps allowed. The customer installs the software and it is good to go.


For those interested, I'm using the C# control Httplistener and PowerShell.



Some of my research:




  1. https://stackoverflow.com/questions/11403333/httplistener-with-https-support

  2. https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/

  3. http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/

  4. https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly










share|improve this question







New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 4





    TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

    – HBruijn
    8 hours ago


















1















My company is creating presentation software. When in use, presenters sign on through an HTTPS enabled web site to send text, documents, authentication tokens, etc.



My question is this: How do I enable HTTPS communication when:




  1. There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.

  2. The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)

  3. No manual steps allowed. The customer installs the software and it is good to go.


For those interested, I'm using the C# control Httplistener and PowerShell.



Some of my research:




  1. https://stackoverflow.com/questions/11403333/httplistener-with-https-support

  2. https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/

  3. http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/

  4. https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly










share|improve this question







New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 4





    TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

    – HBruijn
    8 hours ago














1












1








1








My company is creating presentation software. When in use, presenters sign on through an HTTPS enabled web site to send text, documents, authentication tokens, etc.



My question is this: How do I enable HTTPS communication when:




  1. There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.

  2. The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)

  3. No manual steps allowed. The customer installs the software and it is good to go.


For those interested, I'm using the C# control Httplistener and PowerShell.



Some of my research:




  1. https://stackoverflow.com/questions/11403333/httplistener-with-https-support

  2. https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/

  3. http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/

  4. https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly










share|improve this question







New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












My company is creating presentation software. When in use, presenters sign on through an HTTPS enabled web site to send text, documents, authentication tokens, etc.



My question is this: How do I enable HTTPS communication when:




  1. There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.

  2. The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)

  3. No manual steps allowed. The customer installs the software and it is good to go.


For those interested, I'm using the C# control Httplistener and PowerShell.



Some of my research:




  1. https://stackoverflow.com/questions/11403333/httplistener-with-https-support

  2. https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/

  3. http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/

  4. https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly







http-server






share|improve this question







New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 8 hours ago









Trevy BurgessTrevy Burgess

63




63




New contributor




Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Trevy Burgess is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 4





    TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

    – HBruijn
    8 hours ago














  • 4





    TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

    – HBruijn
    8 hours ago








4




4





TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

– HBruijn
8 hours ago





TLS certificates are almost exclusively assigned to host names and not to ip-addresses.It does not matter that a host has only an private use IPv4 address, as long as you are the legitimate owner / delegated_admin of the domain you can get a valid certificate. Also most larger organizations have their own CA and should be able to issue your hosts valid internal use certificates

– HBruijn
8 hours ago










2 Answers
2






active

oldest

votes


















3














If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.



If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.



If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).



Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.





As an aside:




The customer installs the software and it is good to go




That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:




  • Customer may not have internet access from the host so you can't contact an external authority

  • Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them

  • Customer may require auditing of all certificates being issued for internal hostnames


In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.






share|improve this answer

































    2















    No manual steps allowed. The customer installs the software and it is
    good to go.




    If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.




    The web site might be an internal-only site. (https://letsencrypt.org/
    can't reach it.)




    Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.






    share|improve this answer
























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "2"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });






      Trevy Burgess is a new contributor. Be nice, and check out our Code of Conduct.










      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f964119%2fenable-https-on-private-network%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      3














      If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.



      If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.



      If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).



      Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.





      As an aside:




      The customer installs the software and it is good to go




      That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:




      • Customer may not have internet access from the host so you can't contact an external authority

      • Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them

      • Customer may require auditing of all certificates being issued for internal hostnames


      In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.






      share|improve this answer






























        3














        If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.



        If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.



        If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).



        Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.





        As an aside:




        The customer installs the software and it is good to go




        That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:




        • Customer may not have internet access from the host so you can't contact an external authority

        • Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them

        • Customer may require auditing of all certificates being issued for internal hostnames


        In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.






        share|improve this answer




























          3












          3








          3







          If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.



          If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.



          If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).



          Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.





          As an aside:




          The customer installs the software and it is good to go




          That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:




          • Customer may not have internet access from the host so you can't contact an external authority

          • Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them

          • Customer may require auditing of all certificates being issued for internal hostnames


          In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.






          share|improve this answer















          If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.



          If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.



          If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).



          Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.





          As an aside:




          The customer installs the software and it is good to go




          That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:




          • Customer may not have internet access from the host so you can't contact an external authority

          • Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them

          • Customer may require auditing of all certificates being issued for internal hostnames


          In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 4 hours ago

























          answered 4 hours ago









          Mark HendersonMark Henderson

          61.4k29163248




          61.4k29163248

























              2















              No manual steps allowed. The customer installs the software and it is
              good to go.




              If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.




              The web site might be an internal-only site. (https://letsencrypt.org/
              can't reach it.)




              Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.






              share|improve this answer




























                2















                No manual steps allowed. The customer installs the software and it is
                good to go.




                If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.




                The web site might be an internal-only site. (https://letsencrypt.org/
                can't reach it.)




                Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.






                share|improve this answer


























                  2












                  2








                  2








                  No manual steps allowed. The customer installs the software and it is
                  good to go.




                  If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.




                  The web site might be an internal-only site. (https://letsencrypt.org/
                  can't reach it.)




                  Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.






                  share|improve this answer














                  No manual steps allowed. The customer installs the software and it is
                  good to go.




                  If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.




                  The web site might be an internal-only site. (https://letsencrypt.org/
                  can't reach it.)




                  Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 4 hours ago









                  John MahowaldJohn Mahowald

                  9,0811713




                  9,0811713






















                      Trevy Burgess is a new contributor. Be nice, and check out our Code of Conduct.










                      draft saved

                      draft discarded


















                      Trevy Burgess is a new contributor. Be nice, and check out our Code of Conduct.













                      Trevy Burgess is a new contributor. Be nice, and check out our Code of Conduct.












                      Trevy Burgess is a new contributor. Be nice, and check out our Code of Conduct.
















                      Thanks for contributing an answer to Server Fault!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f964119%2fenable-https-on-private-network%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Knooppunt Holsloot

                      Altaar (religie)

                      Gregoriusmis