Re: self signed cert
Actually that was with a Go Daddy purchased cert, not a self signed cert. As it stands, I have my own CA when I made my cert. I suspect I'm not putting all the elements (ca-cert, cert, key) in the right locations. Original Message From: Tomasz Sterna Sent: Saturday, May 7, 2016 8:21 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 16∶51 -0700, użytkownik li...@lazygranch.com napisał: > I know when I used a web hosting company to handle my email, I would > yearly have to blindly trust the new cert. And this exact behavior I'd like to erradicate. Most users do not bother to check whether they are blindly accepting right certificate, or the certificate provided by middle-man. -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 16∶51 -0700, użytkownik li...@lazygranch.com napisał: > I know when I used a web hosting company to handle my email, I would > yearly have to blindly trust the new cert. And this exact behavior I'd like to erradicate. Most users do not bother to check whether they are blindly accepting right certificate, or the certificate provided by middle-man. -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/ signature.asc Description: This is a digitally signed message part
Re: self signed cert
I'm not following you here. You still have encryption with a self signed cert, but no trust. But if you can't trust yourself, who else can you trust? On public wifi without the self signed cert, the conversation could be read, not to mention login credentials. Take "letsencrypt" for example. Prior to adding their certificates to my root store, I could still get encryption, provided I let my browser go ahead. I just could trust the website identity. The Hong Kong Post Office is a CA, but I don't really trust them. ;-) For private use, self signed is fine. Note than in email, you generally set up the mta with "may encrypt". That is how the MITM hacks your email my stripping SSL then allowing a downgrade. (Neither rain nor snow nor a MITM, the mail must go through.) But xmpp doesn't have the downgrade option. Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 11:12 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Cc: Jabber/XMPP software development list Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 09∶40 -0700, użytkownik li...@lazygranch.com napisał: > I suspect you wouldn't want s2s to use a self signed cert, so > allowing two level of verification (c2s and s2s) sounds complex. You > fix one thing in software and you break something else. So, why would you allow self-signed on C2S? Why do you want to use encryption in the first place? So, no one is able to read the conversation, right? But self-signed cert does not give you this... Just a false illusion that you are protected from evesdropping. But self-signed does not protect you from man-in-the-middle attack, so basically still anyone able to tap the wire your transmission is going through is able to read it, with just slightly more effort. > I noticed the online documentation doesn't completely match the xml, > but there are enough comments in the xml that I could get close to > setting it up. It is just the certs that are confusing. Yeah. The real and up to date source of documentation are the comments in the configuration files. -- /o__ (_<^' Practice is the best of all instructors.
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > jabberd2 version(2.3.6) > I followed these instructions: > https://github.com/jabberd2/jabberd2/wiki/InstallGuide-OpenSSLConfigu > ration > [...] > SM : sx (ssl.c:405) secure channel not established, handshake in > progress > SM : sx (ssl.c:59) verify error:num=18:self signed > certificate:depth=0:/C=US/ST=state/L=city/O=none/OU=none > /CN=mydomain.org/emailAddress=webmas...@mydomain.org > I guess I could catch X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT (18) in SSL_CTX_set_verify callback and pass the cert through, but I'm ambivalent about it... We should really discourage use of self-signed certificates. On the other hand, it really speeds-up test deployments. Maybe have it as an opition, to enable if you really-really need to use self-signed certificates? What do you think? -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/ signature.asc Description: This is a digitally signed message part
Re: self signed cert
So the documentation on generating a self signed cert is not correct. Isn't the key generated in that document technically the root CA? Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 5:12 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > How exactly do I specify the cachain for a self signed cert. You need to put your root CA used to sign the cert to the CA certs store specified in 'cachain' option. This is to encourage deployments to stop using self-signed certs, of questionable security, and instead get a real cert. You can get real, widely accepted certs for free. > I get openssl error 18 meaning it can't be verified. Setting > verify-mode='0' didn't help. verify-mode sets how should the server verify client provided certificates. 0 (SSL_VERIFY_NONE[1]) is the default. [1] https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html -- /o__ (_<^' I respect faith, but doubt is what gives you an education.
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > How exactly do I specify the cachain for a self signed cert. You need to put your root CA used to sign the cert to the CA certs store specified in 'cachain' option. This is to encourage deployments to stop using self-signed certs, of questionable security, and instead get a real cert. You can get real, widely accepted certs for free. > I get openssl error 18 meaning it can't be verified. Setting > verify-mode='0' didn't help. verify-mode sets how should the server verify client provided certificates. 0 (SSL_VERIFY_NONE[1]) is the default. [1] https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html -- /o__ (_<^' I respect faith, but doubt is what gives you an education. signature.asc Description: This is a digitally signed message part
