Use Identity::from_pem
#2054
Use Identity::from_pem
#2054
Conversation
Signed-off-by: Michael Pankov <work@michaelpankov.com>
Signed-off-by: Michael Pankov <work@michaelpankov.com>
Signed-off-by: Michael Pankov <work@michaelpankov.com>
Signed-off-by: Michael Pankov <work@michaelpankov.com>
Signed-off-by: Michael Pankov <work@michaelpankov.com>
@jgrund making sure this works with a "proper" certificate proves to be harder than I thought. I can't use LetsEncrypt because they want a public-facing web-server or DNS record, which doesn't make sense for our vagrant cluster or the isolated production environment it mimics. I currently think the only way to actually setup this in production is to use self-signed certificates. At one of my previous employers we had corporate certificates derived from custom Root CA, and that root CA had to be installed manually on each machine and browser separately to add it to chain of trust. So that root CA was self-signed, and I don't think using non-self-signed certificate for this kind of setup makes sense. Point is, I'm not sure anyone buys proper certificates from 3-rd party public authority for TLS on intranet. If that's actually what we want to support, I guess we should get a proper certificate and PK from a provider like digicert. |
There is no such thing like a "proper" certificate (except algorithms and expiration). A certificate is either trusted or not (via a chain of certificates, also known as intermediate certificates). That is whether a certificate is signed by a certificate which is signed by a certificate and so on ... by a certificate which you trust :) A root CA is always self-signed, if some "root CA" is not self-signed, it's an intermediate certificate. |
I'm saying the same, so it's not clear what we wanted to test with "not a self-signed client certificate". We aren't expecting our clients to obtain certificates with publicly trusted root CA (which are usually paid, not free), are we? |
Signed-off-by: Michael Pankov <work@michaelpankov.com>
I've removed |
Hi @mkpankov, The integration tests are picking up the following error from the rust-iml-agent on the storage servers when detecting the filesystem :
Ultimately, it fails to detect the filesystem. |
@johnsonw thanks Will. Did you go to the machine to see that or it's possible to see in Jenkins logs? |
This reverts commit 4914eee. Signed-off-by: Michael Pankov <work@michaelpankov.com>
I've split the patches and this branch passes the tests. |
There are a few outstanding comments, otherwise LGTM |
I was able to get the information from the sos reports (part of the build artifacts) |
Signed-off-by: Michael Pankov <work@michaelpankov.com>
Follow-up issue: #2071 |
* Switch to `from_pem` Signed-off-by: Michael Pankov <work@michaelpankov.com> * Remove authority certificate from identity Signed-off-by: Michael Pankov <work@michaelpankov.com> * Remove unnecessary features Signed-off-by: Michael Pankov <work@michaelpankov.com> * Remove unnecessary PFX and path_exists Signed-off-by: Michael Pankov <work@michaelpankov.com> * Fix documentation Signed-off-by: Michael Pankov <work@michaelpankov.com> * Try not accepting invalid certificates Signed-off-by: Michael Pankov <work@michaelpankov.com> * Revert "Try not accepting invalid certificates" This reverts commit 4914eee. Signed-off-by: Michael Pankov <work@michaelpankov.com> * Handle review comments Signed-off-by: Michael Pankov <work@michaelpankov.com> Co-authored-by: Joe Grund <jgrund@whamcloud.io>
Close #1731
This change is