I followed the instructions here https://wiki.centos.org/HowTos/Https
Checking port 80 I get the file... curl http://localhost/file.html <HTML> <FORM> Working </FORM> </HTML>
Checking port 443 I get and error curl https://localhost/file.html
curl: (60) Peer's certificate issuer has been marked as not trusted by the user. More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
How do I get past this? I was looking to just self sign for https.
Yes I can added the --insecure for curl - but - my other app doesn't seem to work either - perhaps getting the same return message instead of the actual file.
Thanks,
jerry
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
On Jun 15, 2016, at 7:57 AM, Александр Кириллов nevis2us@infoline.su wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Let’s Encrypt:
It is philosophically aligned with the open source software world, rather than act as bait for a company that would prefer to sell you a cert instead.
I’m only aware of one case where you absolutely cannot use Let’s Encrypt, but it also affects the other public CAs: you can’t get a publicly-trusted cert for a machine without a publicly-recognized and -visible domain name. For that, you still need to use self-signed certs or certs signed by a private CA.
On Wed, June 15, 2016 9:17 am, Warren Young wrote:
On Jun 15, 2016, at 7:57 AM, ÐлекÑÐ°Ð½Ð´Ñ ÐиÑиллов nevis2us@infoline.su wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Letâs Encrypt:
It is philosophically aligned with the open source software world, rather than act as bait for a company that would prefer to sell you a cert instead.
I have got question for experts. I just opened settings of Firefox (latest, on FreeBSD), and took a look at the list of Certification Authorities it comes with.
I do see WoSign there (though I'd prefer to avoid my US located servers have certificates signed by authority located in China, hence located sort of behind "the great firewall of China" - call me superstitious).
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates. This means (correct me if I'm wrong) that client has to import one of these Certification Authorities certificates, otherwise server certificate signed by one of these authorities is on the same page with my private Certification Authority (which I used to run for over 10 years, then in my kickstart I had my CA certificate imported into CA of clients - but other clients, like laptops had to download, install and trus my CA certificate). Of course, this is a notch better than "self-signed" server certificates, as you only need to import CA certificate once, whereas you will need to import self-signed server certificates for each of the servers...
Am I missing something?
Also: with CA signing server certificate there is a part that is "verification of identity" of domain or server owner. Namely, that whoever requested certificate indeed exists as physical entity (person, organization or company) accessible at some physical address etc. This is costly process, and as I remember, free automatically signed certificates were only available from Certification Authority whose CA certificated had no chance to be included into CA bundles shipped with browsers, systems etc. For that exact reason: there is "no identity verification". The last apparently is costly process.
So, someone, please, set all of us straight: what is the state of the art today?
Disclaimer: I have purely academic interest in this myself: my institution makes CA signed certificated for my servers at no cost for me, and that authority is in the CA Cert bundles.
Valeri
Iâm only aware of one case where you absolutely cannot use Letâs Encrypt, but it also affects the other public CAs: you canât get a publicly-trusted cert for a machine without a publicly-recognized and -visible domain name. For that, you still need to use self-signed certs or certs signed by a private CA.
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Jun 15, 2016, at 8:02 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I do not see neither starttls.com http://starttls.com/ nor letsencrypt.org http://letsencrypt.org/ between Authorities certificates. This means (correct me if I'm wrong) that client has to import one of these Certification Authorities certificates, otherwise server certificate signed by one of these authorities is on the same page with my private Certification Authority (which I used to run for over 10 years, then in my kickstart I had my CA certificate imported into CA of clients - but other clients, like laptops had to download, install and trus my CA certificate). Of course, this is a notch better than "self-signed" server certificates, as you only need to import CA certificate once, whereas you will need to import self-signed server certificates for each of the servers...
For my personal needs I use free StartSSL certs and the authority appears as StartCom, Ltd. in Firefox.
In my experience it is already a trusted authority in most/all browsers. At least I didn’t have to manually trust it, and I haven’t run into one that complains about it.
On Wed, Jun 15, 2016 at 10:02:57AM -0500, Valeri Galtsev wrote:
On Wed, June 15, 2016 9:17 am, Warren Young wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Letâs Encrypt:
It is philosophically aligned with the open source software world, rather than act as bait for a company that would prefer to sell you a cert instead.
I have got question for experts. I just opened settings of Firefox (latest, on FreeBSD), and took a look at the list of Certification Authorities it comes with.
I do see WoSign there (though I'd prefer to avoid my US located servers have certificates signed by authority located in China, hence located sort of behind "the great firewall of China" - call me superstitious).
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
I'm not an expert by any means, but I use letsencrypt (mostly for testing) and it's always worked for me in FreeBSD with Firefox, without any special effort on my part. You can try https://srobb.net which is using letsencrypt as its cert.
On Wed, June 15, 2016 10:31 am, Scott Robbins wrote:
On Wed, Jun 15, 2016 at 10:02:57AM -0500, Valeri Galtsev wrote:
On Wed, June 15, 2016 9:17 am, Warren Young wrote:
Nowadays it's quite easy to get normal ssl certificates for free.
E.g.
Today, I would prefer LetâÂÂs Encrypt:
It is philosophically aligned with the open source software world,
rather
than act as bait for a company that would prefer to sell you a cert instead.
I have got question for experts. I just opened settings of Firefox (latest, on FreeBSD), and took a look at the list of Certification Authorities it comes with.
I do see WoSign there (though I'd prefer to avoid my US located servers have certificates signed by authority located in China, hence located sort of behind "the great firewall of China" - call me superstitious).
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
I'm not an expert by any means, but I use letsencrypt (mostly for testing) and it's always worked for me in FreeBSD with Firefox, without any special effort on my part. You can try https://srobb.net which is using letsencrypt as its cert.
Thanks, Scott, I made a note, and will use it if there ever will be a need (Now I get certs signed through institutional channel by intermediate authority as well!). Intermediate CAs somehow slept my mind today (I probably missed my morning coffee ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Jun 15, 2016, at 9:02 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I do see WoSign there (though I'd prefer to avoid my US located servers have certificates signed by authority located in China, hence located sort of behind "the great firewall of China" - call me superstitious).
That’s a perfectly valid concern. The last I heard, modern browsers trust 1,100 CAs! Surely some of those CAs have interests that do not align with my interests.
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
That’s because they are not top-tier CAs.
This means (correct me if I'm wrong) that client has to import one of these Certification Authorities certificates
You must be unaware of certificate chaining:
https://en.wikipedia.org/wiki/Intermediate_certificate_authorities
Even top-tier CAs use certificate chaining. The proper way to run a CA is to keep your private root signing key off-line, using it only to sign some number of intermediate CA signing certs, which are the ones used to generate the certs publicly distributed by that CA.
Doing so lets a CA abandon an escaped private key by issuing a CRL for an escaped private key. The CA then just generates a new signing key and continues on with that; it doesn’t have to get its new signing key into all the TLS clients’s trusted signing key stores because the new key’s trust chain goes back to the still-private offline root key.
Without that layer of protection, if their private signing key somehow escapes, the CA is basically out of business until they convince all the major browsers to distribute their replacement public key.
- but other clients, like laptops had to download, install and
trus my CA certificate).
If those laptops are Windows laptops on an AD domain, there is a way to push CA public keys out to them automatically. (Don’t ask me how, I’m not a Windows admin. I’m just aware that it can be done.)
Also: with CA signing server certificate there is a part that is "verification of identity" of domain or server owner. Namely, that whoever requested certificate indeed exists as physical entity (person, organization or company) accessible at some physical address etc. This is costly process, and as I remember, free automatically signed certificates were only available from Certification Authority whose CA certificated had no chance to be included into CA bundles shipped with browsers, systems etc. For that exact reason: there is "no identity verification". The last apparently is costly process.
I’m not exactly sure what you’re asking here. If you are simply pointing out that the free certificate providers — including Let’s Encrypt — do not do public records background checks, D&B checks, phone calls to phone numbers on your web page and DNS records, etc. to prove that you are who you say you are, that is true.
Let’s Encrypt is not in competition with EV certificates, for example:
https://en.wikipedia.org/wiki/Extended_Validation_Certificate
The term of art for what Let’s Encrypt provides is a domain validation certificate. That is, it only proves that the holder was in control of the domain name at the time the cert was generated.
So, someone, please, set all of us straight: what is the state of the art today?
The answer could fill books. In a forum like this, you can only expect answers to specific questions for such broad topics.
On Jun 15, 2016, at 9:38 AM, Warren Young wyml@etr-usa.com wrote:
On Jun 15, 2016, at 9:02 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
That’s because they are not top-tier CAs.
I forgot to mention that letsencrypt.com uses one of its own certificates. You can use your browser’s certificate detail view to see the chain of trust. I see two levels here: IdenTrust -> TrustID -> Let’s Encrypt.
As for starttls.com, that doesn’t exist; you’re probably confusing it with the SMTP STARTTLS protocol extension. What you mean is startssl.com, which is the main public face of StartCom. StartCom is a top-tier CA.
On Wed, June 15, 2016 10:48 am, Warren Young wrote:
On Jun 15, 2016, at 9:38 AM, Warren Young wyml@etr-usa.com wrote:
On Jun 15, 2016, at 9:02 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
Thatâs because they are not top-tier CAs.
I forgot to mention that letsencrypt.com uses one of its own certificates. You can use your browserâs certificate detail view to see the chain of trust. I see two levels here: IdenTrust -> TrustID -> Letâs Encrypt.
Thanks, that means no need to install CA. There is always someone (Thanks, Warren!) who looked deeper into things, and can explain them. The only thing here is: I need to look deeper myself how the identity of the server is ensured in this case (i.e. whether tier 2, tier 3, ... CAs really do that. But that is more fundamental thing: basically with that in play, can I still trust that the physical entity owning server cert is indeed who it claims to be).
As for starttls.com, that doesnât exist; youâre probably confusing it with the SMTP STARTTLS protocol extension. What you mean is startssl.com, which is the main public face of StartCom. StartCom is a top-tier CA.
I'm sure I did copy and paste, so that should have copied from OP e-mail...
Thanks again, Warren,
Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Jun 15, 2016, at 10:40 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Thanks, that means no need to install CA. There is always someone (Thanks, Warren!) who looked deeper into things, and can explain them.
I claimed that the topic fills books. That wasn’t an exaggeration. Back in 1997, I read the first edition of this thick tome:
http://shop.oreilly.com/product/9780596000455.do
The second edition is about 50% bigger, and it’s about 15 years old now, so it could probably be 1,000 pages and still not cover everything about the modern Internet PKI.
I’m not sure I could recommend a book that old in a field that still changes as much as web security does. Perhaps someone else could recommend something more current.
I need to look deeper myself how the identity of the server is ensured in this case
As I said in a prior email, there are different grades of certificate. I mentioned EV and DV. There’s also OV:
https://www.globalsign.com/en/ssl-information-center/types-of-ssl-certificat...
(i.e. whether tier 2, tier 3, …
The tier doesn’t affect how the CA does validation. You could have a very meticulous tier 3 EV provider and a sloppy tier 1 provider that only does DV.
can I still trust that the physical entity owning server cert is indeed who it claims to be).
It’s a chain of trust: the browser vendor trusts these 1,100 CAs, and you trust the browser vendor, so you implicitly trust all of the certs signed, directly or indirectly by those CAs.
If you want to take an active role in this, you need to go into the trust store for the browser(s) you use and remove CAs you do not trust.
On Wed, June 15, 2016 10:38 am, Warren Young wrote:
On Jun 15, 2016, at 9:02 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I do see WoSign there (though I'd prefer to avoid my US located servers have certificates signed by authority located in China, hence located sort of behind "the great firewall of China" - call me superstitious).
Thatâs a perfectly valid concern. The last I heard, modern browsers trust 1,100 CAs! Surely some of those CAs have interests that do not align with my interests.
I do not see neither starttls.com nor letsencrypt.org between Authorities certificates.
Thatâs because they are not top-tier CAs.
This means (correct me if I'm wrong) that client has to import one of these Certification Authorities certificates
You must be unaware of certificate chaining:
https://en.wikipedia.org/wiki/Intermediate_certificate_authorities
Sorry, intermediate authorities just slept off my mind somehow (to say worst: my server certificated _are_ signed by intermediate CA - shame on me ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 15.06.2016 16:17, Warren Young wrote:
On Jun 15, 2016, at 7:57 AM, Александр Кирилловnevis2us@infoline.su wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Let’s Encrypt:
It is philosophically aligned with the open source software world, rather than act as bait for a company that would prefer to sell you a cert instead.
I’m only aware of one case where you absolutely cannot use Let’s Encrypt,
there is more than one case; just think of trust;
lets encrypt only trusts for 3 months; would you really except in an onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
but it also affects the other public CAs: you can’t get a publicly-trusted cert for a machine without a publicly-recognized and -visible domain name. For that, you still need to use self-signed certs or certs signed by a private CA.
A private CA is the same as self signed;
On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
I doubt that most users check the dates on SSL certificates, unless they are familiar enough with TLS to understand that a shorter validity period is better for security.
On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
I doubt that most users check the dates on SSL certificates, unless they are familiar enough with TLS to understand that a shorter validity period is better for security.
Oh, this is what he meant: Cert validity period. Though I agree with you in general (shorter period public key is exposed smaller chance secret key brute-force discovered), logistically as the one who has to handle quite a few certificates, I only will go with certificates valid for a year, or better 2 years. Given a bandwidths and ciphers these certificates still can provide necessary security (I exclude here such things like server system compromises which have nothing to do with the time the server exists or certificate lives on the server - do I miss something?).
Just my $0.02
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
I doubt that most users check the dates on SSL certificates, unless they are familiar enough with TLS to understand that a shorter validity period is better for security.
Oh, this is what he meant: Cert validity period. Though I agree with you in general (shorter period public key is exposed smaller chance secret key brute-force discovered), logistically as the one who has to handle quite a few certificates, I only will go with certificates valid for a year, or better 2 years. Given a bandwidths and ciphers these certificates still can provide necessary security (I exclude here such things like server system compromises which have nothing to do with the time the server exists or certificate lives on the server - do I miss something?).
There is also what use is being made of it. For internal dev websites, for example, not available to the outside world, I create self-signed for one length of time... ten years. By that time, the project, if it's still around, will have gone other ways.
mark
On 06/16/2016 11:23 AM, Valeri Galtsev wrote:
as the one who has to handle quite a few certificates, I only will go with certificates valid for a year, ...do I miss something?).
Yes. The tool that creates certificate/key pairs, submits the CSR, and installs the certificate is intended to be fully automated. In production, you should be running it as an automatic job.
As someone who handles a lot of certificates, I can't imagine why I'd want any other CA to handle my certs (excluding the EV certs).
On Thu, June 16, 2016 3:00 pm, Gordon Messmer wrote:
On 06/16/2016 11:23 AM, Valeri Galtsev wrote:
as the one who has to handle quite a few certificates, I only will go with certificates valid for a year, ...do I miss something?).
Yes. The tool that creates certificate/key pairs, submits the CSR, and installs the certificate is intended to be fully automated. In production, you should be running it as an automatic job.
Should I? Ooops. Not this, please. I do trust more myself installing it manually, and testing results than my buggy scripts or external tools alike (and the ability of these to keep up with possible changes on Certification Authority interface side).
As someone who handles a lot of certificates, I can't imagine why I'd want any other CA to handle my certs (excluding the EV certs).
And here we are on the same page...
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 16.06.2016 20:09, Gordon Messmer wrote:
On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
I doubt that most users check the dates on SSL certificates, unless they are familiar enough with TLS to understand that a shorter validity period is better for security.
technically there is more: not the user needs to check the dates a SSL certificate is valid;
just compare it with real life: which salesman would you trust more - the one that gets a new car every few years, which has the same advertisings on it and maybe has the same color, or the other one that gets nearly every month a new car, which looks totally different, other color and other advertisings on it? (and its not a car dealer)
the same its with SSL certificates; so you have to find the golden middle way, as long as enough without loosing the security and not too short to prevent not to get trust;
Walter
On 06/16/2016 11:50 AM, Walter H. wrote:
technically there is more: not the user needs to check the dates a SSL certificate is valid;
just compare it with real life: which salesman would you trust more - the one that gets a new car every few years, which has the same advertisings on it and maybe has the same color, or the other one that gets nearly every month a new car, which looks totally different, other color and other advertisings on it? (and its not a car dealer)
Your metaphor is extremely strained, and completely unnecessary. It doesn't relate to the reality of certificates in any way.
Without using a metaphor, please explain exactly who you think will not trust these certs, because I have never met these people.
On 16.06.2016 22:02, Gordon Messmer wrote:
Without using a metaphor, please explain exactly who you think will not trust these certs, because I have never met these people.
then you know now, that there exist such people ... at least the folks where their security software (antivirus, whatever) tells them a problem ...
On 06/16/2016 10:50 PM, Walter H. wrote:
On 16.06.2016 22:02, Gordon Messmer wrote:
Without using a metaphor, please explain exactly who you think will not trust these certs, because I have never met these people.
then you know now, that there exist such people ...
Well, one, but I'm hardly going to tailor my security infrastructure to one customer.
at least the folks where their security software (antivirus, whatever) tells them a problem ...
And what security software would report a problem with these certificates? (bearing in mind that ~ 30% of all TLS transactions involve a 90-day certificate, according to telemetry)
On Thu, June 16, 2016 12:53 pm, Walter H. wrote:
On 15.06.2016 16:17, Warren Young wrote:
On Jun 15, 2016, at 7:57 AM, ÐлекÑÐ°Ð½Ð´Ñ ÐиÑилловnevis2us@infoline.su wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Letâs Encrypt:
It is philosophically aligned with the open source software world, rather than act as bait for a company that would prefer to sell you a cert instead.
Iâm only aware of one case where you absolutely cannot use Letâs Encrypt,
there is more than one case; just think of trust;
lets encrypt only trusts for 3 months;
Could you elaborate on that?
Thanks. Valeri
would you really except in an
onlineshop, someone trusts this shop? let us think something like this: "when the CA only trusts for 3 months, how should I trust for a longer period which is important for warranty ..."
but it also affects the other public CAs: you canât get a publicly-trusted cert for a machine without a publicly-recognized and -visible domain name. For that, you still need to use self-signed certs or certs signed by a private CA.
A private CA is the same as self signed;
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Wed, June 15, 2016 16:17, Warren Young wrote:
On Jun 15, 2016, at 7:57 AM, Александр Кириллов nevis2us@infoline.su wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
Today, I would prefer Let’s Encrypt:
here is the better alternative for lazy people
https://www.startssl.com/StartEncrypt
its based on the root certificates of StartSSL and automatic as Let's encrypt;
On 15.06.2016 15:57, Александр Кириллов wrote:
Nowadays it's quite easy to get normal ssl certificates for free. E.g.
that is right, but hink of your potential clients, because wosign has a problem - slow OCSP, ... because their server infrastucture is located in China, and not the best bandwidth ...
when validity checks of the used SSL certificate very probable fail, it is worse than not using SSL ...
Walter
that is right, but hink of your potential clients, because wosign has a problem - slow OCSP, ... because their server infrastucture is located in China, and not the best bandwidth ...
when validity checks of the used SSL certificate very probable fail, it is worse than not using SSL ...
I don't think OCSP is critical for free certificates suitable for small businesses and personal sites.
On 16.06.2016 21:42, Александр Кириллов wrote:
that is right, but hink of your potential clients, because wosign has a problem - slow OCSP, ... because their server infrastucture is located in China, and not the best bandwidth ...
when validity checks of the used SSL certificate very probable fail, it is worse than not using SSL ...
I don't think OCSP is critical for free certificates suitable for small businesses and personal sites.
this is philosophy;
I'd say when you do it then do it good, else don't do it;
Walter H. писал 2016-06-16 22:54:
On 16.06.2016 21:42, Александр Кириллов wrote:
that is right, but hink of your potential clients, because wosign has a problem - slow OCSP, ... because their server infrastucture is located in China, and not the best bandwidth ...
when validity checks of the used SSL certificate very probable fail, it is worse than not using SSL ...
I don't think OCSP is critical for free certificates suitable for small businesses and personal sites.
this is philosophy;
I'd say when you do it then do it good, else don't do it;
Then OCSP stapling is the way to go but it could be a real PITA to setup for the first time and may not be supported by older browsers anyway.
On 17.06.2016 16:27, Александр Кириллов wrote:
Walter H. писал 2016-06-16 22:54:
On 16.06.2016 21:42, Александр Кириллов wrote:
I don't think OCSP is critical for free certificates suitable for small businesses and personal sites.
this is philosophy;
I'd say when you do it then do it good, else don't do it;
Then OCSP stapling is the way to go but it could be a real PITA to setup for the first time and may not be supported by older browsers anyway.
not really, because the same server tells the client that the SSL certificate is good, as the SSL certificate itself; these must be independent;
Walter
Then OCSP stapling is the way to go but it could be a real PITA to setup for the first time and may not be supported by older browsers anyway.
not really, because the same server tells the client that the SSL certificate is good, as the SSL certificate itself; these must be independent;
Says who? Yes, the OCSP response comes from the same server but it's still signed by the issuer CA. OCSP stapling has been developed for a number of reasons including user privacy concerns and I find those reasons quite convincing. The need to revoke an issued certificate before its expiration date is rare. CA error, transfer of the domain ownership, loss of a private key... What else? Yet the origial OCSP implementation gives the interested third parties the ability to track browsing habits of unsuspecting visitors of the sites which do not implement OCSP stapling. This is not to mention much higher traffic the CAs will have to shoulder with the proliferation of secure sites.
On 17.06.2016 19:57, Александр Кириллов wrote:
Then OCSP stapling is the way to go but it could be a real PITA to setup for the first time and may not be supported by older browsers anyway.
not really, because the same server tells the client that the SSL certificate is good, as the SSL certificate itself; these must be independent;
Says who?
the logic; anything you do to reduce problems or to prevent problems connecting to SSL sites because of slow OCSP servers or similar reduces security itself ...
Yes, the OCSP response comes from the same server but it's still signed by the issuer CA.
yes and no, but faking a valid OCSP response that says good instead of revoked is also possible ...
OCSP stapling has been developed for a number of reasons including user privacy concerns and I find those reasons quite convincing.
the primary reason was to prevent problems for connection problems - or whatever problems - in connection with the OCSP
The need to revoke an issued certificate before its expiration date is rare.
maybe; but Heartbleed showed us something different ...;
Yet the origial OCSP implementation gives the interested third parties the ability to track browsing habits of unsuspecting visitors of the sites which do not implement OCSP stapling. This is not to mention much higher traffic the CAs will have to shoulder with the proliferation of secure sites.
of course; if there would be only one CA, and there would be only SSL, this CA would know what hosts you connect in your browser, because of OCSP ...
but the privacy concerns in this connections is less than the tracking cookies where a little bit more of information is sent ... (with OCSP they know only which IP address is verifying which certificate and what time)
yes and no, but faking a valid OCSP response that says good instead of revoked is also possible ...
Could you please provide any proof for that statement? If it were true the whole PKI infrastructure should probably be thrown out of the window. )
the primary reason was to prevent problems for connection problems - or whatever problems - in connection with the OCSP
Sure. I've never said privacy concerns were the main reason.
Security concerns can probably be addressed with reducing update interval of issuer-signed OCSP responses. For my free wosign certificates ii's 4 days and my understanding is that interval matches CRL update policy of the CA.
Per RFC2560 (see nextUpdate below):
2.4 Semantics of thisUpdate, nextUpdate and producedAt
Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. The semantics of these fields are:
- thisUpdate: The time at which the status being indicated is known to be correct - nextUpdate: The time at or before which newer information will be available about the status of the certificate - producedAt: The time at which the OCSP responder signed this response.
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
On 17.06.2016 22:39, Александр Кириллов wrote:
yes and no, but faking a valid OCSP response that says good instead of revoked is also possible ...
Could you please provide any proof for that statement? If it were true the whole PKI infrastructure should probably be thrown out of the window. )
question back: is the SHA2 discussion a real security impact or just paranoia?
so provide a proof of the following statement:
"using OCSP Stapling is as secure as not using OCSP Stapling"
just think of the "parallel universe" called real life ...
do you believe a car dealer that a used car is ok, or do you want a proof by third party? (here the car dealer is the server and 3rd pardy is the OCSP server or CRL provided by the CA)
for me I refuse it or in other words, when there is no OCSP response and I don't get a CRL from the CA the SSL-host is blocked;
On Jun 15, 2016, at 7:47 AM, Jerry Geis geisj@pagestation.com wrote:
Yes I can added the --insecure for curl - but - my other app doesn't seem to work either - perhaps getting the same return message instead of the actual file.
Because of all the security holes people have been finding in TLS, libraries implementing the client side of TLS are getting increasingly intolerant of risky configurations.
It’s too bad, because self-signed certificates are only unusual on the public Internet. I wish the designers of TLS had included a flag in the cert that let it declare that it was only to be trusted on a private intranet by clients of that same intranet.
For example, instead of declaring that the given server is foo.example.com, it would be nice if you could generate a self-signed cert that declares that it is for 172.16.69.42, and that any host on 172.16.69.0/24 should trust it implicitly.
Such a cert could not be used to prove identity, prevent spoofing, or prevent MITM attacks, but it would give a way to set up encryption, which is often all you actually want. MITM attacks could be largely prevented with certificate pinning.
-----Original Message----- From: Warren Young Sent: Wednesday, June 15, 2016 10:26 To: CentOS mailing list Subject: Re: [CentOS] https and self signed
On Jun 15, 2016, at 7:47 AM, Jerry Geis geisj@pagestation.com wrote:
Yes I can added the --insecure for curl - but - my other
app doesn't
For the love of all that is holy, create your own CA and have your own PKI, even for testing.
seem to work either - perhaps getting the same return
message instead
of the actual file.
...
It's too bad, because self-signed certificates are only unusual on the public Internet. I wish the designers of TLS
...
self-signed cert that declares that it is for 172.16.69.42, and that any host on 172.16.69.0/24 should trust it implicitly.
It is very easy to creat your own CA, to sign your own certs. There is no need to support self signed "leaf nodes" of the PKI.
I have taken some liberties on this to save me time, you will need to change config values to suit your needs.
$ mkdir -p CA/{private,certs} $ cd CA # copy the default openssl config $ cp -v "$(openssl ca -verbose 2>&1 | head -n 1 | sed 's/Using configuration from //')" . $ sed -i 's/^(\s*dir\s*=.*)/#\1\ndir=./' openssl.cnf $ sed -i 's|^(\s*certificate\s*=.*)|#\1\ncertificate=$dir/CA.crt|' openssl.cnf $ sed -i 's|^(\s*private_key\s*=.*)|#\1\nprivate_key=$dir/private/CA.key|' openssl.cnf $ sed -i 's|^(\s*new_certs_dir\s*=.*)|#\1\nnew_certs_dir=$dir/newcerts|' openssl.cnf $ touch index.txt # done setting up the file system $ openssl req -config openssl.cnf -new -nodes -keyout private/CA.key -out CA.csr # answer the questions $ openssl ca -config openssl.cnf -batch -in CA.csr -create_serial -selfsign # there should only be one cert, the CA's self signed cert $ cp certs/*.pem CA.crt # done creating the CA
# now you can sign your server certificate signing requests (CSR)
# make a csr
#sign server.csr $ openssl ca -config openssl.cnf -batch -in server.csr
#files at end of email for understanding...
Such a cert could not be used to prove identity, prevent spoofing, or prevent MITM attacks, but it would give a way to set up encryption, which is often all you actually want. MITM attacks could be largely prevented with certificate pinning.
And reducing the trusted CA set in your enterprise.
$ cat ./private/CA.key -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDEHcq8mOpHHD+H /qDNPpsG2GkRyj8wt9LVIltmUqwqIBlNe3nlxHEHg9YJExPbTTXERehNkpF8HPtM S2rfcYMz2Cjq8C8CzNlC/Ur2a8GKfOufZU9a+gv8I2CXzah6DLkdZqqCsnC/dTPL bRLPBlmmwldl3pcOpF1hmMF1CzCwDAx2V31ZijLHlMfd+cRdssfYk1D4ntGRBK+0 78g2/nBOKQsD6ajTXHwaH7eeV7BRasjGodSud8cJ1uhD0E3QLpW466sYmM1SGdgy 1mbuJYGnfHVy4zScDy7yQb4EvoQZOYOMJymETCQfk86B43Sncs20TEpDW2N48N+O pbqM0TAxAgMBAAECggEAIt45IXb+kE4RbZhz9one/kSTybnvqjXEomhNX8/rFEJI vWHqtlNK1U83Sr29lgwQNylGuCQLAcoVU+dExR1lel5ASCUT9qd9KU/neBCIhJrZ OanFhiNW5ilUDyldfvWsI/IQ9tPK//9SiiSGZ5B1eBStfUsqCExo3eVO4ARxT5tF Fug/XgyV5vdUnUFC/axQPCWNfkFlm6mXNBcVO+D7/kweklrKLGqIFQTSv7mzL5ya nTslER6dTu/2gva6cVAw3PN8FjgFa85ISpAWcyZ7ZBHd2evL46V1WsxFOsu5Ish+ e4SPP0xf4+8VggNvPruPb0T3gV8jHbN4fyPGqH7DwQKBgQDmbg2Mj69WN1jw1EpH agv2xzVqTnjQSdbD2YBJ8ZJqIolAZigdrLTXp/P/pnOXe+3up1S+9OGbktQAc9DN i9zf6Wn9NyZ323YEfL2MLE8pRrLsFFw1+fVG/BNcrHMOnt3rSQ7v2LhGe/kLCIQh RKDSf83sEvAcfcSCpWeoZRlnxQKBgQDZ4PnrBpUVm86cq9/RV4Ax0NJ7+u+ybLj5 tKEeEDRlzTyNv2KIF7MOWoK6EMBw3N/YloSp41Zm7UXAdwjJHrxZ3GrlHvYqJDaW cGX+GjncDpcM2GIh4tcuhnKTdUZc/eGWPZRA97EPdhqwHbDaPLSrQhtDmPDCWVNs DqyWPFbBfQKBgH7tuEDpFOgk7LUb+x6DZ7uz19SLDTmOsuKG+IfCragRBhGXNBnE fIkeVuVHxvx2o4WGXsQhF/UeV/E32piepjgg1uVIb8Qt+0BVhgOklKZj70LjpDeH THihefjedTJkiFGGmNe9RSRuPay6MC4zI3NQOxoDBIhtLsXYXtT/e5MRAoGAY48t RFsmptAikm7rgGJmftz4QZUCENsjj18dvHoVJ2uoPvF0WdHSjT2IvPNIrIoRc4wc JPFwGupTVEZQam60DK/u3LHQNKOFmirUQE/FnqvAFCuQdAGO6IChPIZ7V6Tff2K2 KxXD/9etDEsU9DSHLjav9KyfX3+n4hm2fZQm5JUCgYB1tiDFrX4kgf671A9eMXHa 4RJKtvKdXEzw/a1uU82rvShZnlfIijHOHnOduwpFbtZRjvwREslBjwe0KXC5n4rN ontb9cb94SmJlrYWj0ZYGbECB2nh1xBq2IeF7ly8t6Ky5xRc9hcACX5Z5G0QfHf8 liGhEmq+iGBkYtW6Jucvbg== -----END PRIVATE KEY-----
$ cat ./certs/FC4B076EEDAC665F.pem -----BEGIN CERTIFICATE----- MIIELjCCAxagAwIBAgIJAPxLB27trGZfMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYD VQQGEwJVUzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMg UHR5IEx0ZDEZMBcGA1UECwwQVHJ1c3QgRGVwYXJ0bWVudDEYMBYGA1UEAwwPUHJp dmF0ZSBSb290IENBMSMwIQYJKoZIhvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNv bTAeFw0xNjA2MTUxNjI3MzBaFw0xNzA2MTUxNjI3MzBaMIGXMQswCQYDVQQGEwJV UzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0 ZDEZMBcGA1UECwwQVHJ1c3QgRGVwYXJ0bWVudDEYMBYGA1UEAwwPUHJpdmF0ZSBS b290IENBMSMwIQYJKoZIhvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQdyryY6kccP4f+oM0+mwbYaRHK PzC30tUiW2ZSrCogGU17eeXEcQeD1gkTE9tNNcRF6E2SkXwc+0xLat9xgzPYKOrw LwLM2UL9SvZrwYp8659lT1r6C/wjYJfNqHoMuR1mqoKycL91M8ttEs8GWabCV2Xe lw6kXWGYwXULMLAMDHZXfVmKMseUx935xF2yx9iTUPie0ZEEr7TvyDb+cE4pCwPp qNNcfBoft55XsFFqyMah1K53xwnW6EPQTdAulbjrqxiYzVIZ2DLWZu4lgad8dXLj NJwPLvJBvgS+hBk5g4wnKYRMJB+TzoHjdKdyzbRMSkNbY3jw346luozRMDECAwEA AaN7MHkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0 ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFIO7y8JqSyD+EuhnoPYVNMKn0bsfMB8G A1UdIwQYMBaAFIO7y8JqSyD+EuhnoPYVNMKn0bsfMA0GCSqGSIb3DQEBCwUAA4IB AQBHNAQKoJ6+aToFbuDhHxBt0KBF0dJ3ZR6PbmI35zclwA7FIUWAzAfK71oBYGhT 3ALqU2Klc3CogacKD/lk18MvVLdyIKrZ7fx7gMzfmB9tqb1qRWr6AaoLRLUOXzBt c6wHwwvKCNGyr28giQohPwa4YfdngFUI1uWr5SAeGlUoAPv23gJsN49aUu+nX6HU lqwofRjikXtB+xlBYa3J8RYwv+Al7cCuAvWLU8coQ5NxxlfXGNzF+8kZNWcqu7xr s6OKoO6t5rENhlIohI1Ijk0MLH5zKMgphn09m5aCiWdNu4lcfeI6lTSmpd8spGiD vgREOnejICHw4IUIwRyqCT2g -----END CERTIFICATE-----
$ cat ./certs/FC4B076EEDAC6660.pem -----BEGIN CERTIFICATE----- MIIEHzCCAwegAwIBAgIJAPxLB27trGZgMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYD VQQGEwJVUzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMg UHR5IEx0ZDEZMBcGA1UECwwQVHJ1c3QgRGVwYXJ0bWVudDEYMBYGA1UEAwwPUHJp dmF0ZSBSb290IENBMSMwIQYJKoZIhvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNv bTAeFw0xNjA2MTUxNjMwNTNaFw0xNzA2MTUxNjMwNTNaMIGIMQswCQYDVQQGEwJV UzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0 ZDEQMA4GA1UECwwHU2VydmVyczESMBAGA1UEAwwJMTI3LjAuMC4xMSMwIQYJKoZI hvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMbCfmkw9xCxYOY7H51yKFsTB6A8WI1+NUqiCP7vAswXRkeh ENKY5+hv2yUuRdbRJ9Or8bF3qaNyuWYm4xgCIN2hTwF9yk2egBvWt9gGMn7L/wTL qTEC9M7dXDWkf0SAtIQ6H6ReQO2PkzGEHik3cyr/Ba91eP2rsGBjs5xh7Bax/iU2 nBvpZgEvQYaLFCm+5awwnzw7XaIWCs1EUa3gosOH1AuJXQTqGLYu9MWZ2rzWUFu9 XDmEwPqyl+fmnhg2Z90cUeZtdfxuhOOaUdEunbFxGpUDDYZrZ7FiMaKXMQae32zD SOeEf1GzmxeuD0KuE4TSRRyiFn9HlivwJinze+sCAwEAAaN7MHkwCQYDVR0TBAIw ADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUw HQYDVR0OBBYEFA+HggkRbrlN0jZH3yuUlpnE8m7DMB8GA1UdIwQYMBaAFIO7y8Jq SyD+EuhnoPYVNMKn0bsfMA0GCSqGSIb3DQEBCwUAA4IBAQArsEuv2FLXED8bxFcQ F6LWp1PltCmK45L4Pr+tTWooNhyKBOGQRm+ZwxfuQ7ASN/dachaTXCvmjlCQf7Xt pqDWLX9i+yOYfX0bOn2AH/SVEncyH0pu7QIvHrnHanpwDaeBBpciagYfIKoFaBjU gBHpFBBiQxU6NNlYCZmgvNSxeUQ6HjMOMYnr7++qmlAUnjcVwBB9MeQyrg+eSYk2 MSWFm+9ltx7RbChAA3ELFvHv5MzOKADobTzp5UDUQ+FOPty9ODnPGPeExXlsO9Yj F9/uuqzKACOg4oOmh9s0V8GPCMGVuDgoxuxOjPuWuscYPaBSUsD2eEzdjdL82FtA pGnp -----END CERTIFICATE-----
On 6/15/2016 6:47 AM, Jerry Geis wrote:
How do I get past this? I was looking to just self sign for https.
in my admittedly limited experience with this stuff, you need to create your own rootCA, and use that to sign your certificates, AND you need to take the public key of the rootCA and import it into any trust stores that will be used to verify said certificates.
On Wed, 15 Jun 2016, John R Pierce wrote:
On 6/15/2016 6:47 AM, Jerry Geis wrote:
How do I get past this? I was looking to just self sign for https.
in my admittedly limited experience with this stuff, you need to create your own rootCA, and use that to sign your certificates, AND you need to take the public key of the rootCA and import it into any trust stores that will be used to verify said certificates.
If you don't do this, then there's no real point using SSL at all, and you *should* be forced to override security with arguments:
wget --no-check-certificate curl --insecure
etc.
jh
John Hodrien wrote:
On Wed, 15 Jun 2016, John R Pierce wrote:
On 6/15/2016 6:47 AM, Jerry Geis wrote:
How do I get past this? I was looking to just self sign for https.
in my admittedly limited experience with this stuff, you need to create your own rootCA, and use that to sign your certificates, AND you need
to take
the public key of the rootCA and import it into any trust stores that will be used to verify said certificates.
If you don't do this, then there's no real point using SSL at all, and you *should* be forced to override security with arguments:
wget --no-check-certificate curl --insecure
Or, maybe, you're working in a domain, and one upper level website is set up with https-use-strict recursive, so it breaks *everything* below.... I'd like to be able to say "but not me" in the website configuration page - maybe it just throws up a warning, to remind you to pull it when it goes live, but for dev & test....
mark, really tired of it breaking our *internal* documentation wiki for me
On Wed, 15 Jun 2016, John R Pierce wrote:
On 6/15/2016 6:47 AM, Jerry Geis wrote:
How do I get past this? I was looking to just self sign for https.
in my admittedly limited experience with this stuff, you need to create your own rootCA, and use that to sign your certificates, AND you need to take the public key of the rootCA and import it into any trust stores that will be used to verify said certificates.
The EasyRSA scripts make creating and using your own Certificate Authority as painless as X.509 can be (which is to say, there will still be some pain). You can find them in the OpenVPN distribution tarball or at GitHub:
https://github.com/OpenVPN/easy-rsa
-
David Nelson -
Gordon Messmer -
Jason Pyeron -
Jerry Geis -
John Hodrien -
John R Pierce -
m.roth＠5-cent.us -
Paul Heinlein -
Scott Robbins -
Valeri Galtsev -
Walter H. -
Warren Young -
Александр Кириллов