Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added information about appliance certificates #677

Merged
merged 6 commits into from
Sep 7, 2017

Conversation

stuclem
Copy link
Contributor

@stuclem stuclem commented Aug 29, 2017

Fixes #526

Towards #424

@zjs I seem to have adopted you as my go-to guy for all things security related. Can you please review? Thanks!

Copy link
Member

@zjs zjs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

http://<i>vic_appliance_address</i>

Should these addresses be http or https? (I don't know how this aspect of VIC works, but if we can recommend https it seems like we should.)


2. Delete any client certificates or CAs for older instances of vSphere Integrated Containers appliances or VCHs.
3. Clear the browser history, close, and restart Chrome.
4. Connect to the vSphere Integrated Containers Getting Started page, vSphere Integrated Containers Management Portal, or VCH Administration portal again, and trust the certificate.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and trust the certificate

Do we have existing documentation we should refer to for this step? Should users blindly trust whatever certificate is presented, or do we recommend a process for verifying that the expected certificate is presented?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. PR #663 includes details about how to verify the VC/ESXi cert, but we need similar information for the appliance and VCH certs. Will investigate. Thanks @zjs !

@stuclem
Copy link
Contributor Author

stuclem commented Aug 30, 2017

Thanks @zjs. Regarding HTTP vs HTTPS, there is now a redirect in place, so if you just enter http://vic_appliance_address it sends you automatically to the Getting Started page at https://vic_appliance_address:9443.

@stuclem
Copy link
Contributor Author

stuclem commented Aug 30, 2017

@zjs I added a line that users should verify the certificate before trusting it, but don't yet include details about how they might do that. @andrewtchin, is there a way for users to see an auto-generated self-signed certificate for the OVA appliance so that they can check it, rather than just blindly accepting it?

@stuclem
Copy link
Contributor Author

stuclem commented Aug 30, 2017

@andrewtchin if users just examine the cert in Firefox or Chrome, is there something that they should check to make sure that it's legit? Can they download the cert from anywhere and install it, so that they don't see the security warning any more?

@@ -0,0 +1,27 @@
# Browser Rejects Certificates with `ERR_CERT_INVALID` Error #

Attempts to connect to vSphere Integrated Containers web interfaces fail with certificate errors in Google Chrome browsers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would assume other browsers too if using self signed certs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm now that I read further down, based on the inbound links to this ts, it may be worthwhile to distinguish this from the CA not being recognized error that all users using self signed certs will see

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thought is that it is limited to Chrome. Firefox, for example, warns you that the connection isn't secure but then allows you to make an exception for this site. Chrome just locks you out.

@andrewtchin
Copy link
Contributor

@stuclem they would have to SSH in or use the console to the appliance and look at the certificate. They could then compare it to what appears in their browser. With the self signed cert the user can't determine its legitimacy by just looking in their browser - they either need to compare to what's on the appliance or trust the CA. To trust the CA they also need to SSH in to the appliance to obtain the CA certificate. We can document how to do this - let me know.

@stuclem
Copy link
Contributor Author

stuclem commented Aug 30, 2017

@andrewtchin yes I think that this is definitely worth documenting. I matches what we are adding to the docs about verifying the VC/ESXi hosts, i.e. SSH in and examine the cert.

@andrewtchin
Copy link
Contributor

I'll get you a draft for this. I also added a task to display the fingerprint on the DCUI once we share a single cert amongst all components on the appliance. When this is implemented the user would only need to use the vSphere console to verify the self signed cert

@andrewtchin
Copy link
Contributor

andrewtchin commented Aug 30, 2017

To verify Getting Started Page self-signed certificate

  • Navigate to the Getting Started Page at https://<appliance IP>:9443
  • View the certificate details in the browser (steps vary by browser) and locate the SHA-256 Fingerprint
  • Use SSH or DCUI to access the VIC appliance console and login
  • Execute openssl x509 -in /opt/vmware/fileserver/cert/server.crt -noout -sha256 -fingerprint
  • Compare the output of this command to the SHA-256 Fingerprint displayed in the browser - they should be equal

To trust the certificate authority used to sign Getting Started Page self-signed certificate

  • Use SSH or DCUI to access the VIC appliance console and login
  • Copy the file /opt/vmware/fileserver/cert/ca.crt to the machine you want to trust the CA on
  • Follow OS specific procedures to add the copied ca.crt to the root certificate store on the machine

To verify Admiral and Harbor self-signed certificate

  • After VIC Appliance is initialized, navigate to https://<appliance IP>:8282
  • View the certificate details in the browser (steps vary by browser) and locate the SHA-256 Fingerprint
  • Use SSH or DCUI to access the VIC appliance console and login
  • Execute openssl x509 -in /data/admiral/cert/server.crt -noout -sha256 -fingerprint
  • Compare the output of this command to the SHA-256 Fingerprint displayed in the browser - they should be equal

To trust the certificate authority used to sign Admiral and Harbor self-signed certificate

  • Use SSH or DCUI to access the VIC appliance console and login
  • Copy the file /data/admiral/cert/ca.crt to the machine you want to trust the CA on
  • Follow OS specific procedures to add the copied ca.crt to the root certificate store on the machine

Note: the separate procedure won't be needed after vmware/vic#5640
Also the Demo VCH installer generates the cert each time it starts and doesn't save it to disk so we can't really do anything about verifying that at this point.

@stuclem
Copy link
Contributor Author

stuclem commented Aug 31, 2017

Fabulous, thank you @andrewtchin !

@stuclem stuclem changed the title Added troubleshooting topic about browser cert errors Added information about appliance certificates Aug 31, 2017
@stuclem
Copy link
Contributor Author

stuclem commented Aug 31, 2017

This PR has morphed into a general update of certificates information.

@andrewtchin I rejigged your contribution above to divide it into what the vSphere Admin does and what anyone who logs in to the VIC MP does. I also attempted to add a reference for all of the certificates at play in VIC. Do we need to bring anyone else in to review this now more-extensive-than-expected PR?

@andrewtchin
Copy link
Contributor

@zjs would be good to review this. Zach, what do you think about verifying the self signed certificate by looking at the SHA1 fingerprint vs SHA256?

@stuclem
Copy link
Contributor Author

stuclem commented Aug 31, 2017

@andrewtchin ah yes, I changed it from SHA256 to SHA1 because Chrome doesn't show the SHA-256 thumbprint, at least as far as I could find.

@andrewtchin
Copy link
Contributor

it's not easily accessible - it's at the bottom
screen shot 2017-08-31 at 10 16 16 am

@zjs
Copy link
Member

zjs commented Sep 1, 2017

Zach, what do you think about verifying the self signed certificate by looking at the SHA1 fingerprint vs SHA256?

This seems like a classic security vs. usability question. Checking the SHA-256 fingerprint would be more secure, but if we make the procedure too hard/complicated its less likely people will follow it at all. Given that, and given the specific way that SHA-1 has been broken in practice, I think we're fine providing instructions using the SHA-1 thumprint for now.

@andrewtchin
Copy link
Contributor

Agreed on all points

@stuclem
Copy link
Contributor Author

stuclem commented Sep 4, 2017

OK thanks @zjs. So are you good to go on this PR? Did you review the content, specifically docs/user_doc/vic_vsphere_admin/vic_cert_reference.md? Thanks!

Copy link
Member

@zjs zjs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This generally looks good to me.

|vCenter Server or ESXi host|Self-signed or custom|Required for installation of the vSphere Client plug-ins and deployment and management of virtual container hosts (VCHs). See [Obtain the Certificate Thumbprint of vCenter Server or an ESXi Host](obtain_thumbprint.md).|vSphere administrator|
|vSphere Integrated Containers Management Portal|Self-signed or custom|Authenticates connections from browsers to vSphere Integrated Containers Management Portal. See [Obtain the Thumbprints and CA Files of the vSphere Integrated Containers Appliance Certificates](obtain_appliance_certs.md) and [Verify and Trust vSphere Integrated Containers Appliance Certificates](../vic_cloud_admin/trust_vic_certs.md).|Cloud and DevOps admininistrators, developers|
|vSphere Integrated Containers Registry|Self-signed|Authenticates connections to vSphere Integrated Containers Registry instances from Docker clients, replication of projects between registry instances, and registration of additional registry instances in the management portal. See [Configure System Settings](../vic_cloud_admin/configure_system.md).|Cloud and DevOps admininistrators, developers|
|vSphere Integrated Containers file server|Self-signed or custom|Authenticates connections to the Getting Started page, downloads of vSphere Integrated Containers Engine binaries, and the installation of vSphere Client plug-ins. See [Obtain the Thumbprints and CA Files of the vSphere Integrated Containers Appliance Certificates](obtain_appliance_certs.md) and [Verify and Trust vSphere Integrated Containers Appliance Certificates](../vic_cloud_admin/trust_vic_certs.md).|vSphere administrator, Cloud and DevOps admininistrators, developers|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vSphere Integrated Containers file server

I wonder if we have a better external name for this component, but I'm not sure what it would be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what we've been calling it everywhere. I am trying (and failing) to think of a better name...

|vSphere Integrated Containers Management Portal|Self-signed or custom|Authenticates connections from browsers to vSphere Integrated Containers Management Portal. See [Obtain the Thumbprints and CA Files of the vSphere Integrated Containers Appliance Certificates](obtain_appliance_certs.md) and [Verify and Trust vSphere Integrated Containers Appliance Certificates](../vic_cloud_admin/trust_vic_certs.md).|Cloud and DevOps admininistrators, developers|
|vSphere Integrated Containers Registry|Self-signed|Authenticates connections to vSphere Integrated Containers Registry instances from Docker clients, replication of projects between registry instances, and registration of additional registry instances in the management portal. See [Configure System Settings](../vic_cloud_admin/configure_system.md).|Cloud and DevOps admininistrators, developers|
|vSphere Integrated Containers file server|Self-signed or custom|Authenticates connections to the Getting Started page, downloads of vSphere Integrated Containers Engine binaries, and the installation of vSphere Client plug-ins. See [Obtain the Thumbprints and CA Files of the vSphere Integrated Containers Appliance Certificates](obtain_appliance_certs.md) and [Verify and Trust vSphere Integrated Containers Appliance Certificates](../vic_cloud_admin/trust_vic_certs.md).|vSphere administrator, Cloud and DevOps admininistrators, developers|
|VCHs|None, self-signed, or custom|Authenticates connections from Docker clients to VCHs. See [VCH Deployment Options](vch_installer_options.md#security).|vSphere administrator, Cloud and DevOps admininistrators, developers |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VCHs

Nit-pick: this seems to be the only plural row (even though we expect that we may have more than one of other things, like ESXi hosts). Maybe it should just be "VCH" for consistency?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. Fixed in 91f1818. And I like nit-picky!

@stuclem stuclem merged commit e40c902 into vmware:master Sep 7, 2017
@stuclem stuclem deleted the chromecert branch September 7, 2017 07:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants