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;
}
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:
- There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.
- The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)
- 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:
- https://stackoverflow.com/questions/11403333/httplistener-with-https-support
- https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/
- http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/
- https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly
http-server
New contributor
add a comment |
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:
- There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.
- The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)
- 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:
- https://stackoverflow.com/questions/11403333/httplistener-with-https-support
- https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/
- http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/
- https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly
http-server
New contributor
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
add a comment |
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:
- There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.
- The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)
- 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:
- https://stackoverflow.com/questions/11403333/httplistener-with-https-support
- https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/
- http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/
- https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly
http-server
New contributor
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:
- There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.
- The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)
- 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:
- https://stackoverflow.com/questions/11403333/httplistener-with-https-support
- https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/
- http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/
- https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly
http-server
http-server
New contributor
New contributor
New contributor
asked 8 hours ago
Trevy BurgessTrevy Burgess
63
63
New contributor
New contributor
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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.
add a comment |
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
.
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
edited 4 hours ago
answered 4 hours ago
Mark Henderson♦Mark Henderson
61.4k29163248
61.4k29163248
add a comment |
add a comment |
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
.
add a comment |
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
.
add a comment |
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
.
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
.
answered 5 hours ago
John MahowaldJohn Mahowald
9,0811713
9,0811713
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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