WEBVTT 00:00:00.000 --> 00:00:04.240 Welcome back to vSphere 8 in the real world, and now we're going to discuss certificate management. 00:00:06.720 --> 00:00:12.120 So certificates are used for quite a few things in a vSphere environment. Certificates are, they're pretty important. 00:00:12.120 --> 00:00:15.440 They're pretty important to manage, to have secure, to do correctly. 00:00:16.400 --> 00:00:20.240 VMware makes it very, very easy to use just default. 00:00:20.840 --> 00:00:24.680 We installed this. This is what it came with. This is like a self-signed certificate. 00:00:24.959 --> 00:00:33.080 This is what the VMware certificate manager is going to assign by default to host and just don't touch it and it will run. 00:00:33.400 --> 00:00:41.959 The problem is that it won't necessarily be very secure because the certificates aren't signed by a trusted CA. 00:00:42.240 --> 00:00:48.439 So any bad actor could jump in there and put in some dummy site and your system's going to tell you, I don't trust that certificate. 00:00:48.720 --> 00:00:50.040 Well, it tells you that every time. 00:00:50.279 --> 00:00:54.959 And so you're going to say, that's okay, ignore it and trust the certificate and let's keep going forward and log me into vCenter. 00:00:55.400 --> 00:01:01.279 And you're going to put in credentials and you're putting credentials in to a site with a certificate you don't trust. 00:01:01.480 --> 00:01:04.000 And you expect to not trust it, so it's okay. 00:01:04.440 --> 00:01:10.879 And a bad actor could put a phishing site out there and, you know, steal traffic, you know, and redirect it to his site. 00:01:11.279 --> 00:01:15.000 And you put in your single sign-on credentials for your active directory domain. 00:01:15.320 --> 00:01:20.320 And this is going to be an account that has elevated privileges in your domain because you're logging into vCenter. 00:01:20.720 --> 00:01:21.720 What else can you access? 00:01:21.720 --> 00:01:23.559 Those same AD credentials. 00:01:24.239 --> 00:01:25.959 And you can start hacking away. 00:01:26.919 --> 00:01:40.320 So it's a good idea to actually spend some energy, some time to configure your certificate services to get a trusted certificate from a root CA that the computers in your network trust. 00:01:40.360 --> 00:01:42.120 So you're going to get a trusted root certificate. 00:01:42.120 --> 00:01:47.239 So you can put it into, it's going to be a certificate issuing certificate from a trusted root CA. 00:01:47.879 --> 00:02:04.360 So that way, when vCenter issues certificates to the ESXi host and issues certificates to AutoDeploy and issues certificates to vCenter, things like that, then you will see, oh, yeah, this is a trusted certificate. 00:02:04.360 --> 00:02:05.879 And your address bar will be green. 00:02:06.080 --> 00:02:07.680 You know it's a trusted certificate. 00:02:07.959 --> 00:02:12.279 The name matches the certificate name, name the address bar. 00:02:12.720 --> 00:02:15.000 And again, from a CA that you trust. 00:02:15.360 --> 00:02:16.440 So you should be good to go. 00:02:16.479 --> 00:02:27.080 You should be able to continue to move forward with this and have a high level of confidence that it's really the site you think you're connecting to, as well as when your ESXi hosts talk to each other. 00:02:27.399 --> 00:02:32.919 There's a high level of confidence between them that this really is the host I think I'm talking to, right? 00:02:32.960 --> 00:02:34.360 Our communication is protected. 00:02:34.360 --> 00:02:36.919 Our fault-tolerant VM communication is protected. 00:02:37.880 --> 00:02:39.919 VM motion communication is protected. 00:02:40.279 --> 00:02:41.160 All those kinds of things. 00:02:41.160 --> 00:02:57.440 When I'm encrypting virtual machines, I'm using certificates from a trusted CA because my vCenter certificate management services is giving me certificates to encrypt the encryption keys I use to encrypt my virtual machines. 00:02:57.639 --> 00:03:01.279 That key is encrypted with a certificate that we trust, right? 00:03:01.320 --> 00:03:02.039 Things like that. 00:03:02.360 --> 00:03:06.880 So it's a good idea for your certificate environment to be trusted. 00:03:07.600 --> 00:03:18.279 So that means configuring your certificate management server, and that means getting a certificate issuing certificate from a trusted root CA that is trusted by your environment. 00:03:18.559 --> 00:03:21.880 An example they use here on this slide is GoDaddy. 00:03:21.919 --> 00:03:23.479 GoDaddy is one of many. 00:03:23.479 --> 00:03:26.679 GoDaddy, they make it super, super easy, which is a great thing. 00:03:27.440 --> 00:03:28.279 A lot of people use it. 00:03:28.279 --> 00:03:29.880 GoDaddy is trusted by a lot of people. 00:03:29.880 --> 00:03:35.119 They have a really robust infrastructure for revoking certificates if they get compromised and things like that. 00:03:35.559 --> 00:03:38.279 But they are by far not the only one out there. 00:03:38.279 --> 00:03:41.960 There's a lot of them out there that are reputable that you can trust, okay? 00:03:42.559 --> 00:03:46.559 GoDaddy is just a very common one that a lot of people use just because of the convenience. 00:03:46.839 --> 00:03:51.160 Network solutions is obviously another one that a lot of people use, a lot of people trust. 00:03:51.160 --> 00:03:52.399 And there's a lot of them out there. 00:03:52.399 --> 00:03:53.479 This is a couple of examples. 00:03:54.479 --> 00:04:06.160 So certificates are used for encrypting communication between hosts, for encrypting communication between vCenter and the host, for encrypting communication between your vCenter client and the vCenter server, right? 00:04:06.160 --> 00:04:07.479 It's for signing tokens. 00:04:07.479 --> 00:04:08.639 It's for authentication. 00:04:08.639 --> 00:04:11.119 So it's used for a lot of different things in your vCenter environment. 00:04:12.240 --> 00:04:22.760 You would like to have a certificate from a root certificate authority that you trust that is going to be issuing a certificate issuing certificate to your VMware certificate authority. 00:04:22.959 --> 00:04:34.040 So that way, when it issues certificates, they are going to be signed by that certificate, which is signed by a root CA, again, that your organization, that your environment is going to trust. 00:04:35.640 --> 00:04:37.799 So certificate management is done in a lot of different places. 00:04:38.000 --> 00:04:43.119 vCenter, obviously, the vCenter client is going to trust certificates, have a certificate. 00:04:43.519 --> 00:04:45.079 vCenter itself has a certificate. 00:04:45.079 --> 00:04:53.320 So the vCenter management utility is going to manage certificates and give certificates to your host and to your vCenter, different components like that. 00:04:53.799 --> 00:04:57.720 There are some CLI tools that you can use for managing your certificates. 00:04:58.079 --> 00:05:02.480 So the DIR-CLI is used for managing certificates for basically user accounts. 00:05:02.480 --> 00:05:03.679 You can create user accounts. 00:05:04.040 --> 00:05:06.000 You can modify, change user accounts. 00:05:06.000 --> 00:05:11.799 You can use this tool to change users' passwords and to either assign or change a user certificate. 00:05:11.920 --> 00:05:13.279 It is from the DIR-CLI. 00:05:13.920 --> 00:05:19.359 The CERT tool is for managing certificates themselves that are going to be in your environment. 00:05:19.359 --> 00:05:25.200 So you can use this to query and look at certificates, get information about expiration and things like that. 00:05:25.640 --> 00:05:30.000 And then the VEC-SCLI, that is for your vSphere certificate services. 00:05:30.279 --> 00:05:37.239 And that is used for, like, issuing, requesting a certificate for, like, you know, public and private key. 00:05:37.640 --> 00:05:42.320 You can look at it to view certificate requests, things like that for managing your certificate environment from a command line. 00:05:43.079 --> 00:05:46.200 And, of course, your web client also manages certificates, right? 00:05:46.760 --> 00:05:49.959 So the VMCA, that is the VM certificate authority. 00:05:50.000 --> 00:05:53.679 That's the default certificate authority in your vSphere environment, right? 00:05:53.959 --> 00:05:59.000 That is going to be trusted by all the other devices within your vSphere environment. 00:05:59.279 --> 00:06:04.720 It's trusted by the ESXi host and it's going to be trusted by your vCenter server, for example. 00:06:05.079 --> 00:06:11.600 But, of course, the certificate from the ESXi host or from vCenter to your desktop isn't going to necessarily trust that. 00:06:12.000 --> 00:06:23.040 So that's why you might want to get a certificate issuing certificate to assign to the VCMA so that your clients also trust the certificates from that environment. 00:06:23.279 --> 00:06:23.640 Okay. 00:06:24.959 --> 00:06:27.799 So it manages all your certificates, very low overhead, super easy. 00:06:27.799 --> 00:06:29.920 Lots of tasks are automated within that environment. 00:06:29.920 --> 00:06:36.799 So you don't have to worry about, you know, going in and, you know, assigning and approving and installing certificates on a bunch of machines. 00:06:37.160 --> 00:06:41.839 Used to be before this, we would go and get certificates from, like, say, for GoDaddy, for example. 00:06:42.320 --> 00:06:47.239 And we'd go in there, you know, to our ESXi host and we'd install this wildcard certificate on a bunch of ESXi hosts. 00:06:47.239 --> 00:06:49.480 And we'd have to go to every single one and install certificates. 00:06:49.480 --> 00:06:53.640 And someone would spend a day or two installing certificates, you know, once a year or so. 00:06:55.079 --> 00:06:58.320 vCenter doesn't accept a wildcard certificate. 00:06:58.320 --> 00:07:01.720 So we'd have to get a certificate specifically for that vCenter name. 00:07:02.200 --> 00:07:04.160 But now we don't have to really do any of all that. 00:07:04.160 --> 00:07:10.440 We just need to get a Certificate Issuing Certificate for our vCMA and let it manage certificates in my vCenter environment for me. 00:07:13.640 --> 00:07:16.399 So managing certificates in the vCenter client. 00:07:16.679 --> 00:07:19.920 So, again, you want a trusted root certificate, right? 00:07:20.359 --> 00:07:22.559 And we want to get an SSL certificate, right? 00:07:22.559 --> 00:07:27.519 So we want a certificate for a Certificate Issuing Certificate from a trusted root CA. 00:07:27.720 --> 00:07:33.839 We want SSL certificates so we can make sure our web services and things like that, when we connect to devices, 00:07:33.839 --> 00:07:34.679 are re-entrusted. 00:07:35.200 --> 00:07:36.720 Certificate Replacement and Renewal. 00:07:36.720 --> 00:07:41.640 So certificates, if you get them from a third party, they're going to need to be renewed every year. 00:07:41.640 --> 00:07:43.640 So every year you go in, they're going to get a new certificate. 00:07:43.799 --> 00:07:45.519 You can get them for longer periods of time. 00:07:45.519 --> 00:07:49.079 It's generally considered not a good practice to have them last for a really long time. 00:07:49.359 --> 00:07:52.959 You want them for, you know, usually they issue them for two years, which means they're going to be good for a year. 00:07:52.959 --> 00:07:54.959 And you're going to replace them at half their life every year. 00:07:57.359 --> 00:08:03.359 You can also revoke them if you do get one for longer and for some reason all of a sudden 00:08:04.399 --> 00:08:10.559 you think it's compromised, you can go to your trusted root CA and ask them to revoke your certificate. 00:08:10.559 --> 00:08:15.920 Or you can go to your certificate management server and say to revoke that certificate for you also, right? 00:08:16.720 --> 00:08:22.200 So a CSR is a certificate request. 00:08:22.720 --> 00:08:25.160 So you can go in and, you know, look at these requests. 00:08:25.160 --> 00:08:28.160 When a client's going to say, I need a certificate, it's just a request. 00:08:28.799 --> 00:08:34.799 And the certificate authority is going to then approve that request and send you your certificate, all right? 00:08:35.599 --> 00:08:37.840 And you can also review details on your certificate. 00:08:37.840 --> 00:08:42.159 You can go in, if you see in your browser, you can click on it and say you want to view the certificate itself. 00:08:42.400 --> 00:08:48.000 It'll tell you who issued it, the date it was issued on, the date it's going to expire, the date that the root certificate 00:08:48.640 --> 00:08:52.880 expires, as well as the date that your certificate was issued to you is going to expire. 00:08:53.039 --> 00:08:57.200 So hosts are provided certificates by the VCMA, right, by default. 00:08:57.200 --> 00:09:00.719 So when you first install a host, it has a self-signed certificate. 00:09:00.719 --> 00:09:04.320 When you join into vCenter, it gets a new certificate from the VCMA, 00:09:04.320 --> 00:09:07.840 and that certificate is going to be trusted within your vSphere environment. 00:09:08.400 --> 00:09:11.919 AutoDeploy also has its own certificate that it stores itself, 00:09:11.919 --> 00:09:16.479 and this certificate is going to be a sub-certificate for the VCMA, right? 00:09:16.559 --> 00:09:22.559 So, AutoDeploy also has its own managed certificate that it matches to, and it stores on its own storage. 00:09:25.359 --> 00:09:28.000 So certificates require permission. 00:09:28.000 --> 00:09:33.520 Certificate, in order to manage certificates, you can go into your advanced, I'm sorry, 00:09:33.520 --> 00:09:37.919 go into your roles, and then go to your privileges, and certificate.manageCertificates 00:09:37.919 --> 00:09:39.840 is going to be required by default. 00:09:39.840 --> 00:09:44.320 You know, for example, you're going to be required to have a certificate.manageCertificates. 00:09:45.280 --> 00:09:49.679 For example, your administrator at vSphere.local, it has all these permissions. 00:09:49.679 --> 00:09:53.840 If you want to create a new specific user and role for managing certificates, 00:09:53.840 --> 00:09:57.520 this is the privilege it's going to need to do that, right? 00:09:57.520 --> 00:10:02.000 And the certificate is going to need the ESXi host name and IP address. 00:10:02.000 --> 00:10:06.799 That's going to be in the certificate, so when you connect to the host and it sends you a certificate, 00:10:06.799 --> 00:10:10.559 that certificate name is going to match what you have in your address bar. 00:10:14.320 --> 00:10:19.679 So when you upgrade an ESXi host, if you've, you know, it's going to retain a certificate. 00:10:19.679 --> 00:10:25.760 So whatever certificate it got from the VCMA, when you upgrade the host, it's going to keep 00:10:25.760 --> 00:10:27.919 the same name and same IP address and all of that. 00:10:27.919 --> 00:10:29.679 It's also going to keep that same certificate. 00:10:29.679 --> 00:10:32.000 That is going to be retained through the upgrade process. 00:10:34.880 --> 00:10:42.400 So uploading to a data store, it's really common if you don't have a certificate in your VCMA 00:10:42.400 --> 00:10:46.400 that your client machine trusts, right? 00:10:46.400 --> 00:10:50.159 So the VCMA and the ESXi host all trust it and that's why they can all talk to each other, 00:10:50.799 --> 00:10:51.359 right? 00:10:51.359 --> 00:10:54.960 But if you don't have a trusted certificate, what happens is you might go 00:10:56.479 --> 00:11:01.200 to your vCenter environment and you can go to the data stores, go to a data store and say, 00:11:01.200 --> 00:11:04.320 oh, I want to put an ISO on this data store. 00:11:04.320 --> 00:11:06.239 So you click on upload, right? 00:11:06.239 --> 00:11:10.080 You click the upload button and you browse to the ISO you want to upload. 00:11:10.880 --> 00:11:13.359 And you say you want to upload it there and it fails. 00:11:13.359 --> 00:11:17.919 Like right away it's going to fail because the certificates aren't trusted. 00:11:17.919 --> 00:11:24.320 And that is very, very common unless you have trusted certificates by a trusted root CA. 00:11:24.320 --> 00:11:28.559 So then what you have to do to work around that is download a tool like say, for example, 00:11:29.599 --> 00:11:37.440 WinSCP, enable SSH on a host that has access to that data store and then WinSCP into that 00:11:37.440 --> 00:11:44.320 host and then browse to the data store and use a tool like WinSCP to copy the ISO over that way. 00:11:44.320 --> 00:11:48.159 So it works and it's a bunch more steps. 00:11:48.159 --> 00:11:50.159 You need another tool, you need to enable SSH. 00:11:51.200 --> 00:11:52.159 It's a bunch of steps. 00:11:52.719 --> 00:11:56.719 But honestly, normally it's actually a lot faster to do it that way than to do it through 00:11:56.719 --> 00:11:57.440 your browser. 00:11:57.440 --> 00:12:01.359 So doing it through your browser, if you have all the right certificates and things, 00:12:01.359 --> 00:12:05.039 it's fewer steps, it's easier, but it's usually pretty slow. 00:12:05.039 --> 00:12:09.039 And doing it through a tool like WinSCP is a bunch more steps, but actually it usually 00:12:09.039 --> 00:12:10.479 happens a lot faster. 00:12:10.479 --> 00:12:13.119 So it's up to you which way you want to do it. 00:12:13.119 --> 00:12:16.719 So just keep that in mind that you will have uploading to your data stores through your 00:12:16.719 --> 00:12:21.280 browser if your vSphere client fails, if you don't have the trusted certificates. 00:12:23.599 --> 00:12:27.919 So we discussed certificate manager and managing certificates with the vSphere client.