WEBVTT

0:00:02.580000 --> 0:00:08.480000
 When you're dealing with network or
 internet security, cloud security,

0:00:08.480000 --> 0:00:12.460000
 encryption of course is going to be something
 that is critically important.

0:00:12.460000 --> 0:00:16.060000
 And in this video, we're going to take
 a look at some of the ways that

0:00:16.060000 --> 0:00:21.320000
 we can configure TLS certificates
 and use TLS certificates in Azure.

0:00:21.320000 --> 0:00:25.660000
 Now I've got the title as configure
 SSL slash TLS certificates.

0:00:25.660000 --> 0:00:29.520000
 And the reason for that is because really
 it's TLS and really should be

0:00:29.520000 --> 0:00:31.460000
 using at least TLS 1.2.

0:00:31.460000 --> 0:00:36.660000
 But it is still, and I'm certainly guilty
 of this, it is still sometimes

0:00:36.660000 --> 0:00:39.880000
 commonly referred to as SSL
 because that's what it was.

0:00:39.880000 --> 0:00:43.500000
 Anyways, going to have that I will
 try to always remember to say TLS,

0:00:43.500000 --> 0:00:47.720000
 but if I say SSL, please do remember
 that I am referring to TLS.

0:00:47.720000 --> 0:00:49.880000
 So what are we referring
 to overall?

0:00:49.880000 --> 0:00:50.980000
 What do you want to talk about?

0:00:50.980000 --> 0:00:53.520000
 Okay, well, we're going to talk about
 some of the ways that certificates

0:00:53.520000 --> 0:00:57.740000
 are used. We're going to look at TLS certificates
 as they're used in application

0:00:57.740000 --> 0:00:59.760000
 services or app services.

0:00:59.760000 --> 0:01:07.020000
 And we're also going to look at an option,
 a capability called TLS termination.

0:01:07.020000 --> 0:01:10.580000
 Okay, I'm going to talk about custom
 storage account domains and kind

0:01:10.580000 --> 0:01:12.240000
 of how that plays in
 with certificates.

0:01:12.240000 --> 0:01:16.880000
 And we'll also look at how Azure AD
 uses certificates and what are some

0:01:16.880000 --> 0:01:18.960000
 of the ways that we can
 use certificates there.

0:01:18.960000 --> 0:01:21.960000
 Now I'm not going through every
 possible certificate scenario.

0:01:21.960000 --> 0:01:25.460000
 For example, there's a number of certificates
 that are used if you're

0:01:25.460000 --> 0:01:29.660000
 using Azure Kubernetes service, but
 those are covered there and those

0:01:29.660000 --> 0:01:34.140000
 aren't really central necessarily to
 what you're going to always be doing

0:01:34.140000 --> 0:01:37.160000
 in Azure. Not that any of this is always,
 but it's just a little more

0:01:37.160000 --> 0:01:41.240000
 common. And I do talk about the certificates
 in other videos for Azure

0:01:41.240000 --> 0:01:42.200000
 Kubernetes service.

0:01:42.200000 --> 0:01:44.380000
 Anyways, let's move on.

0:01:44.380000 --> 0:01:47.560000
 Okay, TLS certificates in
 application services.

0:01:47.560000 --> 0:01:51.380000
 And this is going to be web apps and
 API apps and function apps primarily.

0:01:51.380000 --> 0:01:53.880000
 And a couple things you should do.


0:01:53.880000 --> 0:01:56.200000
 First of all, you should
 require a CTS.

0:01:56.200000 --> 0:01:59.380000
 Do not allow unencrypted
 traffic to your web app.

0:01:59.380000 --> 0:02:02.280000
 That's just a simple security
 best practice.

0:02:02.280000 --> 0:02:07.560000
 And you should also require TLS 1.2
 unless you have a very good reason

0:02:07.560000 --> 0:02:11.700000
 not to. Okay, now I have or later there
 because my hope is that this video

0:02:11.700000 --> 0:02:13.020000
 is going to be around
 for a decade.

0:02:13.020000 --> 0:02:17.800000
 And there's probably going to be later
 versions by the time maybe the

0:02:17.800000 --> 0:02:19.340000
 last person watches this video.

0:02:19.340000 --> 0:02:22.760000
 But in any case, at the time of this
 recording, it's going to be 1.2.

0:02:22.760000 --> 0:02:26.180000
 And if you're going to use custom domains,
 what that means is that you

0:02:26.180000 --> 0:02:31.040000
 have to bind certificates for the custom
 domain with your application

0:02:31.040000 --> 0:02:35.300000
 service. And I'm going to demonstrate
 that, but not right at the moment.

0:02:35.300000 --> 0:02:41.200000
 Now, another thing to think about
 is an option that's available.

0:02:41.200000 --> 0:02:44.540000
 And I'll talk about where it's available,
 which is TLS termination.

0:02:44.540000 --> 0:02:47.940000
 And I want to go ahead and kind of just
 walk through this just a little

0:02:47.940000 --> 0:02:50.520000
 bit and describe what it is.

0:02:50.520000 --> 0:02:54.740000
 Okay, if I've got a web app, so let's
 say I've got a web app over here.

0:02:54.740000 --> 0:02:59.600000
 And I've got a user labeled the
 web app in just a moment.

0:02:59.600000 --> 0:03:01.640000
 So I'm going to use over here.

0:03:01.640000 --> 0:03:06.240000
 There's my user.

0:03:06.240000 --> 0:03:09.080000
 Okay, here's my web app.

0:03:09.080000 --> 0:03:16.880000
 Right, and let's say that I am restricting
 communication to HTTPS.

0:03:16.880000 --> 0:03:20.060000
 Right, well, there's fantastic.

0:03:20.060000 --> 0:03:23.620000
 It's what you want to do, but there are
 some, I don't want to say drawbacks,

0:03:23.620000 --> 0:03:25.400000
 but considerations you
 have to take into.

0:03:25.400000 --> 0:03:29.700000
 First of all, if you're not familiar
 with HTTP, then, or even if you are,

0:03:29.700000 --> 0:03:30.900000
 it's still true.

0:03:30.900000 --> 0:03:33.900000
 There's a handshake process, and this is
 a simplification, but it's essentially

0:03:33.900000 --> 0:03:40.580000
 what happens. So if I go and I navigate
 to an HTTPS endpoint, what's going

0:03:40.580000 --> 0:03:42.460000
 to happen is I'm not going
 to get the data right away.

0:03:42.460000 --> 0:03:44.600000
 I go through a handshake process.

0:03:44.600000 --> 0:03:49.920000
 The web app is going to send me their
 public certificate with a public

0:03:49.920000 --> 0:03:52.920000
 key, and it's an asynchronous key.


0:03:52.920000 --> 0:03:58.820000
 And then my browser is going to generate
 a synchronous key, so same key

0:03:58.820000 --> 0:04:00.500000
 both sides, but it's encrypted.

0:04:00.500000 --> 0:04:05.000000
 Then it's going to encrypt it with
 that public encryption key and send

0:04:05.000000 --> 0:04:10.260000
 it back. Okay, and then once I have
 established that HTTPS connection,

0:04:10.260000 --> 0:04:12.820000
 then I can start to communicate.

0:04:12.820000 --> 0:04:17.480000
 Right, so really all of that, I'll
 just say HS for handshake.

0:04:17.480000 --> 0:04:22.640000
 Now, once you establish this handshake
 with a server, it's going to be

0:04:22.640000 --> 0:04:28.340000
 cached, but if you're in a load balancing
 scenario, that means that, you

0:04:28.340000 --> 0:04:31.980000
 know, if you get bounced from different
 servers, it's going to have to

0:04:31.980000 --> 0:04:33.280000
 go back through that process.

0:04:33.280000 --> 0:04:36.500000
 Also, there's a simple process
 of encryption and decryption.

0:04:36.500000 --> 0:04:40.200000
 Right, I'm going to send data over, but
 I need to encrypt that data, which

0:04:40.200000 --> 0:04:42.240000
 is a big E there.

0:04:42.240000 --> 0:04:45.360000
 Right, and then I send that data over
 my browser, encrypts it, and it

0:04:45.360000 --> 0:04:49.540000
 sends it over to the web app, which
 in turn needs to decrypt it.

0:04:49.540000 --> 0:04:55.940000
 Okay, and that decryption is a processor
 load, and in fact, as, you know,

0:04:55.940000 --> 0:05:01.080000
 encryption technologies continue, and
 as the encryption keys get larger,

0:05:01.080000 --> 0:05:03.940000
 that becomes more of a
 processing overhead.

0:05:03.940000 --> 0:05:09.200000
 Right, now, none of this is bad, but
 we do have what is called, again,

0:05:09.200000 --> 0:05:13.660000
 SSL TLS, sorry, termination.

0:05:13.660000 --> 0:05:18.180000
 Okay, and what that does is we'll kind
 of wipe out all of this, not everything

0:05:18.180000 --> 0:05:24.620000
 but those. Okay, so I can take a device,
 a system, a service, and I can

0:05:24.620000 --> 0:05:26.140000
 put that in the middle.

0:05:26.140000 --> 0:05:30.140000
 Okay, now the user is still going
 to communicate with that service.

0:05:30.140000 --> 0:05:43.400000
 Useful if I get the right
 drawing tool, there we go.

0:05:43.400000 --> 0:05:52.760000
 Okay, you also have the encryption, transmission
 over the public internet,

0:05:52.760000 --> 0:05:55.320000
 and then decryption at this side.

0:05:55.320000 --> 0:05:59.360000
 Okay, and then I could take that decrypted
 data and send it directly over,

0:05:59.360000 --> 0:06:05.420000
 let's say, to a web app within Azure,
 or I could say I don't want any

0:06:05.420000 --> 0:06:13.300000
 unencrypted transmission, so I could re
-encrypt that based on the encryption

0:06:13.300000 --> 0:06:17.920000
 of the web app, which
 could then decrypt it.

0:06:17.920000 --> 0:06:22.640000
 Right, now, regardless of whether I'm
 going to go with option one or option

0:06:22.640000 --> 0:06:29.080000
 two, there are a number of advantages
 to this kind of architecture.

0:06:29.080000 --> 0:06:33.760000
 First and foremost is that you're giving
 another layer of protection to

0:06:33.760000 --> 0:06:38.480000
 your web app, and in fact, this is
 integrated with two services right

0:06:38.480000 --> 0:06:43.660000
 now, two services that provide SSL termination,
 TLS termination, sorry.

0:06:43.660000 --> 0:06:47.760000
 Also, provide web application
 firewall.

0:06:47.760000 --> 0:06:51.600000
 Right, so I've got this capability, or
 you could have your own third party

0:06:51.600000 --> 0:06:52.640000
 tool doing this, right?

0:06:52.640000 --> 0:06:56.880000
 I could go and deploy a network of virtual
 appliance doing the same thing.

0:06:56.880000 --> 0:06:59.900000
 Okay, so I've got that extra
 layer of security.

0:06:59.900000 --> 0:07:04.480000
 Also, it's the handshake is going to
 be cached between the clients, so

0:07:04.480000 --> 0:07:08.700000
 even if that client gets bounced between
 different back end servers, it's

0:07:08.700000 --> 0:07:13.040000
 going to be transparent, and that overhead
 is going to be taken away.

0:07:13.040000 --> 0:07:18.980000
 Right, and if I take that option one
 where the data is decrypted at the

0:07:18.980000 --> 0:07:25.920000
 SSL termination point, sorry, I told
 you, if it's decrypted there, then

0:07:25.920000 --> 0:07:29.440000
 I don't have the overhead, the encryption
 and decryption overhead on the

0:07:29.440000 --> 0:07:32.020000
 back end web application, right?

0:07:32.020000 --> 0:07:35.180000
 And really doesn't matter if it's a
 web application running as platform

0:07:35.180000 --> 0:07:40.000000
 as a service, or if it's running on
 infrastructure as a service on a VM.

0:07:40.000000 --> 0:07:41.540000
 Okay, same concept.

0:07:41.540000 --> 0:07:46.560000
 All right, now, again, the two services
 right now that provide this capability

0:07:46.560000 --> 0:07:58.480000
 are the front door service, and you're
 not watching me write too much.

0:07:58.480000 --> 0:08:02.700000
 I'm going to say App Gway
 for application gateway.

0:08:02.700000 --> 0:08:07.140000
 And they're essentially set up
 with the same capabilities.

0:08:07.140000 --> 0:08:10.380000
 The process set it up is a little bit
 different, but you've got a front

0:08:10.380000 --> 0:08:14.180000
 end, you've got it back end, and you've
 got rules that are going to take

0:08:14.180000 --> 0:08:18.700000
 care of this. All right, so
 that is SSL termination.

0:08:18.700000 --> 0:08:23.800000
 All right, now some of the other things
 that we have to discuss here.

0:08:23.800000 --> 0:08:25.200000
 Okay, custom storage
 account domains.

0:08:25.200000 --> 0:08:28.600000
 Now, here's the thing.

0:08:28.600000 --> 0:08:33.460000
 You can have custom domain names
 for your storage account.

0:08:33.460000 --> 0:08:40.280000
 You can also have and even require a CTS
 transmission for any communication

0:08:40.280000 --> 0:08:42.920000
 with the storage API.

0:08:42.920000 --> 0:08:45.940000
 In other words, any tools, any
 way you're going to access it.

0:08:45.940000 --> 0:08:49.640000
 Okay, the problem is you can't have
 them both at the same time because

0:08:49.640000 --> 0:08:54.960000
 the storage account has no facility
 built into it to really upload the

0:08:54.960000 --> 0:09:02.800000
 application. So you can have
 that encrypted communication.

0:09:02.800000 --> 0:09:05.180000
 Okay, there are alternatives.

0:09:05.180000 --> 0:09:07.840000
 You can use a CDN.

0:09:07.840000 --> 0:09:13.880000
 The Azure Content Delivery Network
 or CDN has the ability to implement

0:09:13.880000 --> 0:09:18.160000
 custom domains with TLS.

0:09:18.160000 --> 0:09:19.760000
 And so that is an option.

0:09:19.760000 --> 0:09:22.060000
 But the other option you want to think
 about is whether or not you even

0:09:22.060000 --> 0:09:24.800000
 really honestly need
 a custom domain.

0:09:24.800000 --> 0:09:28.880000
 Absolutely a good idea and unless you
 have a very good reason not to do

0:09:28.880000 --> 0:09:33.040000
 this, you should require
 encrypted communication.

0:09:33.040000 --> 0:09:37.480000
 But do you need that on a storage
 account with a custom domain?

0:09:37.480000 --> 0:09:42.800000
 A custom domain makes absolute sense
 if you're working with a website,

0:09:42.800000 --> 0:09:46.820000
 right? So if it's a web app or if it's
 a website running on virtual machine,

0:09:46.820000 --> 0:09:48.820000
 right, that's part of your brand.

0:09:48.820000 --> 0:09:56.100000
 So of course you want that to come
 up and to go to iNidemo.com, right?

0:09:56.100000 --> 0:10:00.100000
 But the storage account is that really
 necessarily forward-facing, right?

0:10:00.100000 --> 0:10:07.660000
 Even if you're using it to manage a large
 number of images for your website,

0:10:07.660000 --> 0:10:10.960000
 right? You want the website
 to have that URL.

0:10:10.960000 --> 0:10:14.740000
 But does the storage account
 really need it?

0:10:14.740000 --> 0:10:20.200000
 And that's just something to think about
 when you are designing your applications.

0:10:20.200000 --> 0:10:22.120000
 Okay, moving on.

0:10:22.120000 --> 0:10:25.520000
 Last subject here before we get into
 what is one of my favorite demos

0:10:25.520000 --> 0:10:28.900000
 because it's cool and it's pretty easy
 and it makes sense and it's a good

0:10:28.900000 --> 0:10:32.200000
 thing to do. Azure
 AD certificates.

0:10:32.200000 --> 0:10:38.640000
 Azure AD is our authentication and identity
 service makes sense that it's

0:10:38.640000 --> 0:10:47.280000
 going to have some certificates
 and also some key operations.

0:10:47.280000 --> 0:10:51.200000
 Okay, I've got three listed here and
 for me there, the really kind of

0:10:51.200000 --> 0:10:52.300000
 the biggest three.

0:10:52.300000 --> 0:10:53.860000
 I'll throw another one in there.

0:10:53.860000 --> 0:10:55.400000
 Actually, I've got it right there.


0:10:55.400000 --> 0:10:59.920000
 The first is certificate-based authentication
 for service principles.

0:10:59.920000 --> 0:11:03.740000
 If you're going to run an automated
 process and you want that process

0:11:03.740000 --> 0:11:06.380000
 to authenticate, which you don't want,
 you know, let's say you're running

0:11:06.380000 --> 0:11:09.720000
 a PowerShell script or an Azure CLI
 script, which you really don't want

0:11:09.720000 --> 0:11:14.020000
 to do is you don't want to embed any
 kind of credentials in that script

0:11:14.020000 --> 0:11:17.560000
 because that's just not good
 security practice, right?

0:11:17.560000 --> 0:11:19.640000
 Particularly if it's plain text.

0:11:19.640000 --> 0:11:24.920000
 Okay, but what you can do is you can associate
 a properly registered certificate

0:11:24.920000 --> 0:11:30.940000
 with your service principle and that actually
 can be a self-signed certificate.

0:11:30.940000 --> 0:11:35.880000
 And that way, whenever you access,
 you know, and you authenticate, you

0:11:35.880000 --> 0:11:39.340000
 authenticate by the service principle and
 then it's going to use a certificate

0:11:39.340000 --> 0:11:44.900000
 rather than you having to embed any
 kind of credentials directly into

0:11:44.900000 --> 0:11:50.200000
 your script. In fact, for example, if
 you are using an Azure automation

0:11:50.200000 --> 0:11:55.980000
 account and you're using that to interact
 with the Azure Resource Manager

0:11:55.980000 --> 0:12:00.060000
 pretty much at this point, Azure, then
 you're going to use a certificate

0:12:00.060000 --> 0:12:04.020000
 to do that almost certainly and that's
 how it's designed to work.

0:12:04.020000 --> 0:12:07.400000
 Okay, also application
 identity, right?

0:12:07.400000 --> 0:12:13.840000
 When you set up an application to use
 Azure as its authentication provider

0:12:13.840000 --> 0:12:21.680000
 and its identity provider, there has to
 be a way to confirm the application.

0:12:21.680000 --> 0:12:27.100000
 Now, in some cases, for example, if
 I create an ASP.NET core application

0:12:27.100000 --> 0:12:36.080000
 that is only using the Azure AD for
 interactive applications, it doesn't

0:12:36.080000 --> 0:12:38.620000
 in that case need a secret
 for the application itself.

0:12:38.620000 --> 0:12:42.460000
 But if I've got an application that's
 going to do things on its own, it's

0:12:42.460000 --> 0:12:46.260000
 going to run in the background, then
 there has to be some way for that

0:12:46.260000 --> 0:12:49.660000
 application to be authenticated.

0:12:49.660000 --> 0:12:54.640000
 And one way to do that is to actually
 associate a certificate or a public

0:12:54.640000 --> 0:12:57.200000
 key with an application.

0:12:57.200000 --> 0:13:01.520000
 And then whatever is working with that
 application needs to know that.

0:13:01.520000 --> 0:13:05.800000
 An example of that is the
 Azure Kubernetes service.

0:13:05.800000 --> 0:13:09.940000
 If you're using the Azure Kubernetes
 service, there's actually two active

0:13:09.940000 --> 0:13:13.280000
 directory services that you would use if
 you're using Azure AD authentication

0:13:13.280000 --> 0:13:15.540000
 for it, which you should be.

0:13:15.540000 --> 0:13:21.100000
 And there is a certificate that's used
 for authentication between those

0:13:21.100000 --> 0:13:26.460000
 two services. And finally, certificates
 for federation.

0:13:26.460000 --> 0:13:32.460000
 If I'm using a federation service such
 as ADFS, which is kind of the fact

0:13:32.460000 --> 0:13:37.100000
 that go to federation tool because it's
 frankly well integrated into tools

0:13:37.100000 --> 0:13:39.380000
 like Azure AD Connect.

0:13:39.380000 --> 0:13:41.280000
 But it's not limited to that.

0:13:41.280000 --> 0:13:44.700000
 You can use paying, you can use other
 federation providers as well.

0:13:44.700000 --> 0:13:46.880000
 But there's going to be a couple of
 certificates that are used there.

0:13:46.880000 --> 0:13:50.160000
 One certificate is going to be its
 public certificate because there is

0:13:50.160000 --> 0:13:56.140000
 going to be a public URL DNS name
 that users get redirected to.

0:13:56.140000 --> 0:13:59.980000
 And so of course you have to have that
 and of course going to be secure

0:13:59.980000 --> 0:14:01.660000
 because they're providing
 credentials.

0:14:01.660000 --> 0:14:03.040000
 So you need a certificate.

0:14:03.040000 --> 0:14:05.500000
 There's also a token
 signing certificate.

0:14:05.500000 --> 0:14:10.040000
 Now the token signing certificate is
 can certainly be and certainly with

0:14:10.040000 --> 0:14:12.360000
 ADFS by default is self signed.

0:14:12.360000 --> 0:14:17.740000
 But you can also use certificate authority
 or CA based certificates for

0:14:17.740000 --> 0:14:24.300000
 that as well. But those are just some
 of the areas in Azure AD where you

0:14:24.300000 --> 0:14:29.500000
 would have certificates potentially
 come into play now for the fun part.

0:14:29.500000 --> 0:14:40.440000
 We're going to take
 a look at a web app.

0:14:40.440000 --> 0:14:46.400000
 And then securing that custom domain
 name and then enforcing encrypted

0:14:46.400000 --> 0:14:51.260000
 communication forcing it
 to use HTTPS and TLS 1.2.

0:14:51.260000 --> 0:14:54.740000
 So without further ado,
 let's jump into this.

0:14:54.740000 --> 0:15:00.600000
 All right, I have a web app.

0:15:00.600000 --> 0:15:03.000000
 And right now I'm good
 with the web app.

0:15:03.000000 --> 0:15:07.840000
 And if I go to the web app, it
 goes there and it's got a URL.

0:15:07.840000 --> 0:15:10.460000
 But I'm not really thrilled
 with that URL.

0:15:10.460000 --> 0:15:12.280000
 I want a custom URL.

0:15:12.280000 --> 0:15:19.780000
 Well, fortunately for me, I have my
 own Azure DNS zone, public DNS zone.

0:15:19.780000 --> 0:15:27.080000
 And I already have a C name record
 that just so happens to be pointing

0:15:27.080000 --> 0:15:32.460000
 to my web app almost
 like I planned that.

0:15:32.460000 --> 0:15:35.340000
 Okay, so now what I want to do
 is I want to integrate that.

0:15:35.340000 --> 0:15:37.240000
 So I'm going to go
 back to my web app.

0:15:37.240000 --> 0:15:38.140000
 So I've got a web app.

0:15:38.140000 --> 0:15:39.720000
 I've got a custom domain name.

0:15:39.720000 --> 0:15:41.600000
 I want to put those together.

0:15:41.600000 --> 0:15:45.700000
 And the way I put them together is
 I come over here to custom domains.

0:15:45.700000 --> 0:15:48.220000
 And I don't have any right now.

0:15:48.220000 --> 0:15:50.200000
 I'm going to add a custom domain.

0:15:50.200000 --> 0:15:53.520000
 And I'm going to add TLS dot.

0:15:53.520000 --> 0:15:56.700000
 I need demo dot com.

0:15:56.700000 --> 0:16:00.540000
 And I'm going to validate it, which
 basically looks and makes sure that

0:16:00.540000 --> 0:16:04.880000
 you actually have that domain
 name and that it does.

0:16:04.880000 --> 0:16:08.300000
 And it is in fact pointing
 to this app service.

0:16:08.300000 --> 0:16:09.940000
 And I do. And it is.

0:16:09.940000 --> 0:16:13.620000
 So I'm going to add it.

0:16:13.620000 --> 0:16:20.040000
 Easy enough. Okay.

0:16:20.040000 --> 0:16:26.340000
 And to refresh. And
 it's not showing up.

0:16:26.340000 --> 0:16:28.280000
 I'm on. There we go.

0:16:28.280000 --> 0:16:29.400000
 Took in a minute.

0:16:29.400000 --> 0:16:32.080000
 All right. Now notice also it's
 telling me it's not secure.

0:16:32.080000 --> 0:16:35.340000
 Now I could go and I could
 navigate to that on HTTP.

0:16:35.340000 --> 0:16:36.900000
 And I'm going to ask you
 to take my word for that.

0:16:36.900000 --> 0:16:42.580000
 But what I want to do is I
 actually want to bind this.

0:16:42.580000 --> 0:16:47.520000
 Okay. Now I've got a certificate,
 a private key certificate.

0:16:47.520000 --> 0:16:50.640000
 I actually generated this
 with Let's Encrypt.

0:16:50.640000 --> 0:16:53.060000
 And there's different ways that you can
 upload a private key certificate.

0:16:53.060000 --> 0:16:57.720000
 And I'd recommend taking a look at
 what some of these options are.

0:16:57.720000 --> 0:17:00.240000
 I'm not going to go through all
 of them in demonstration.

0:17:00.240000 --> 0:17:05.440000
 But I am going to go
 and upload a file.

0:17:05.440000 --> 0:17:09.480000
 And again, this is just a file that
 certificate file, PFX file that I

0:17:09.480000 --> 0:17:18.480000
 created using Windows Services
 for Linux and Let's Encrypt.

0:17:18.480000 --> 0:17:22.560000
 All right. So I now
 have a certificate.

0:17:22.560000 --> 0:17:28.000000
 It's warning me because the expiration
 date is coming up.

0:17:28.000000 --> 0:17:29.580000
 But that's fine.

0:17:29.580000 --> 0:17:33.660000
 Now what I need to do is I need
 to bind that certificate.

0:17:33.660000 --> 0:17:38.140000
 So I'm going to go ahead
 and add TLS SSL bindings.

0:17:38.140000 --> 0:17:44.140000
 And I'm going to go ahead
 and pull the TLS INE demo.

0:17:44.140000 --> 0:17:47.940000
 I'm going to pull the
 certificate for that.

0:17:47.940000 --> 0:17:49.240000
 And I'm going to set this up.

0:17:49.240000 --> 0:17:52.980000
 It is an S&I SSL certificate.

0:17:52.980000 --> 0:17:55.820000
 I can do that or IP based,
 but I created this.

0:17:55.820000 --> 0:18:00.160000
 And it generally makes sense that
 you would do this on an S&I SSL.

0:18:00.160000 --> 0:18:02.800000
 All right. And there we go.

0:18:02.800000 --> 0:18:06.580000
 And see, it still says configuring
 SSL binding, even though it's TLS.

0:18:06.580000 --> 0:18:09.060000
 All right. Now the last thing I'm going
 to do is I am going to require

0:18:09.060000 --> 0:18:13.360000
 HTTPS. And notice it's already
 saying that it is version 1.2.

0:18:13.360000 --> 0:18:18.880000
 The only time I ever have trouble with
 this and honestly I haven't done

0:18:18.880000 --> 0:18:23.180000
 it a while, so I don't know if they fixed
 this default, is that the default

0:18:23.180000 --> 0:18:31.200000
 for PowerShell for a good time in
 recent memory has been TLS 1.0.

0:18:31.200000 --> 0:18:35.500000
 And so if I'm trying to connect to
 something that's TLS 1.2, I have to

0:18:35.500000 --> 0:18:38.300000
 change the default setting,
 which is not a big deal.

0:18:38.300000 --> 0:18:41.480000
 But anyways, that's the only place
 I know of that it's really causing

0:18:41.480000 --> 0:18:42.940000
 any kind of issue.

0:18:42.940000 --> 0:18:45.100000
 All right. And now
 it's pretty cool.

0:18:45.100000 --> 0:18:48.700000
 When I go to the overview, it actually
 says, OK, there's your URL there.

0:18:48.700000 --> 0:18:51.560000
 And it actually picks that up, says,
 OK, you put in a custom domain.

0:18:51.560000 --> 0:18:55.020000
 You probably want that
 to be your base URL.

0:18:55.020000 --> 0:18:57.860000
 And by the way, it is
 also ready for HTTPS.

0:18:57.860000 --> 0:18:58.940000
 So we're good there.

0:18:58.940000 --> 0:19:02.440000
 And if I browse to it,
 there we have it.

0:19:02.440000 --> 0:19:05.220000
 So I've gotten to
 my simple web app.

0:19:05.220000 --> 0:19:09.140000
 It's going to understand
 the URL TLS iNEDemo.com.

0:19:09.140000 --> 0:19:13.240000
 And it is using encrypted
 communication.

0:19:13.240000 --> 0:19:17.140000
 Now again, I could also set that up
 with SSL termination using either

0:19:17.140000 --> 0:19:26.740000
 front door or an That's the base process
 of configuring your TLS requirements.