디지털 인증서 사용
각 조직의 Juniper Mist Access Assurance와 통합된 RADIUS 서버용 인증서를 생성하고 사용하려면 다음 단계를 따르십시오.
EAP 인증을 사용하는 경우 클라이언트와 서버 모두 서로의 ID를 확인해야 합니다. 클라이언트는 통신 중인 서버를 신뢰해야 하며 서버는 클라이언트를 인증해야 합니다. 서버 인증서는 이 상호 인증 프로세스의 첫 번째 단계이며 클라이언트는 통신을 진행하기 전에 서버의 유효성을 검사하거나 신뢰해야 합니다.
무선 또는 유선 인증에 관계없이 EAP 트랜잭션(예: EAP-TLS 또는 EAP-TTLS)을 살펴보면 첫 번째 단계는 클라이언트가 클라이언트 장치에 "Server Hello" 메시지를 전송하여 서버를 식별하는 것입니다.
클라이언트 디바이스가 서버 인증서를 수신하면 Wi-Fi 또는 LAN 프로파일에서 신뢰할 수 있는 CA(인증 기관) 목록을 확인하고 서버 인증서가 신뢰할 수 있는 CA 중 하나에 의해 서명되었는지 확인합니다. 선택적으로, 구성된 경우 서버 이름이 클라이언트 구성의 신뢰할 수 있는 서버 이름 목록과 일치하는지 확인합니다.
유효성 검사 단계 및 신뢰 서버 인증서를 우회하지 않는 것이 좋습니다. 이는 보안 위험이 높으며 MITM(중간자) 공격을 열 수 있습니다.
다음 방법 중 하나를 사용하여 각 조직의 Juniper Mist Access Assurance와 통합된 RADIUS 서버에 대한 인증서를 생성하고 사용할 수 있습니다.
- CA Certificate(CA 인증서) - Juniper Mist는 클라이언트 디바이스와의 신뢰를 구축하기 위해 특정 CA 인증서가 필요합니다. 신뢰할 수 있는 CA(인증 기관)에서 발급한 이러한 인증서를 통해 Juniper Mist Access Assurance는 클라이언트 디바이스에 네트워크 액세스 권한을 부여할 수 있습니다. Juniper Mist에 의한 클라이언트 디바이스의 유효성 검사는 디바이스의 인증서 제공을 기반으로 하며, 동일한 CA에서 서명해야 합니다.
- 기본 Juniper Mist Access Assurance 인증서 - Mist 조직은 Access Assurance 서버 인증서 발급을 담당하는 고유한 개인 CA(Mist 인증 기관)를 유지 관리합니다. 특정 구성이 없는 경우 클라이언트는 해당 Mist 조직 CA에서 인증한 기본 인증서를 받게 됩니다. 이 인증서는 도메인 "auth.mist.com"에 해당합니다.
- Custom Server Certificate(사용자 지정 서버 인증서) - 현재 클라이언트 구성을 수정하지 않고 클라이언트가 클라이언트 인증서를 제공한 동일한 CA(Certificate Authority)에서 발급한 서버 인증서를 신뢰하도록 하려는 경우 사용자 지정 서버 인증서가 선호됩니다. RADIUS 서버에서 가져온 개인 키와 서명된 인증서를 입력해야 합니다.
위의 인증서를 사용하는 방법을 이해하려면 다음 절차를 읽으십시오.
CA(인증 기관) 인증서 사용
EAP-TLS(Extensible Authentication Protocol–전송 레이어 Security) 인증서 기반 인증이 작동하려면 Juniper Mist 포털에서 신뢰할 수 있는 CA 인증서를 추가해야 합니다.
이 단계를 통해 Juniper Mist Access Authentication을 사용하여 추가된 CA에서 서명한 클라이언트 인증서를 신뢰할 수 있습니다.
외부 CA에서 인증서를 가져올 수 있습니다. CA는 잘 알려진 공용 CA 또는 엔터프라이즈 CA일 수 있습니다.
다음 비디오를 시청하여 테스트 또는 랩 사용을 위한 인증서를 생성하는 방법을 알아봅니다.
How to create certificates both CA certificates and client certificates that you could use for lab testing to repeat all the steps in our tutorials. So in order to do things easily and quickly, assuming there is no existing infrastructure, assuming there is nothing you can use that you're available on-hand, you could use some open source tools that are out there on the internet. I will use degree-based certificate authority and key management called XCA.
You can Google it. You can download it. It's available for everyone to use. So now, when we will use XCA tool, first thing we will need to do, we'll need to create a new database. You could think of this creating a specific BQ infrastructure right on your laptop. So we can just say missed access insurance tutorial. Database, save it in there, it will ask you to encrypt it, which is a good thing. Click OK. So now we have the database created.
So the first thing we will need to create our certificate infrastructure is the certificate authority. That's the thing that will sign all the certificates of all your client devices that you will be using for testing. And that's the ultimate source of trust in your BQ infrastructure. So I'm going to click on new certificate. I'm going to select that, this is going to be a self-signed certificate because technically, every certificate authority, the root certificate authority is a self-signed.
Has a self-signed certificate. We'll select the template called CA from this list, will then go to subject. We can give it some internal name but doesn't matter, we could just say lab mist CA. You can fill in some of the data in there. Again, it doesn't really matter what you will put in there. But for testing purposes, just use anything you really like, organization name. Common name is important. This is how you identify certificates in real life. So one of the important attributes is common name. And we will take a look at the other one later, which is called the subject alternative name.
So common name, let's just call it lab-mist-ca@justify.com. Maybe something like this. I'm going to click that. We'll need to create a private key. A private key is what will prove that the certificate-- oh, owned and certificate holder is actually that same device or it's same CA. So we'll generate a new key, we'll set it to be 4,000 bytes, create. It will automatically selected here. It's good. We'll go to extensions. The type will be certification authority. It will add a few attributes in the certificate saying this is a CA cert.
This is where we will add the subject to alternative name. So typically what you'll do is you click edit, you will say I want to copy common name and there. Click apply. That's it. This will typically go and take your common name and copy it into a assign attribute.
Nowadays, many clients are using SAN to validate-- certificate validity. And the key usage, what do we need there? We need certificate signs, CRL sign. That's pretty much it. So we'll click OK. This now created our certificate authority in here. So we have the certificate. This is a CA cert, it has a common name.
The expiry date is, well, next year, but typically CA cert would be valid for like 10 years or something like that. For our intents and purposes, this is just a lot testing one year is more than enough.
So what will then need to do is will create a client cert. So click select our CA, will click new certificate. Now see under signing section, we are going to use this CA cert for signing certificates. It's not going to be self-signed anymore. So now our certificate authority will sign a new certificate that will be issued by the client. This is how we will establish this chain of trust. So create, select the template-- TLS client. We'll go to subject. That just say this is going to be a test lab client. Doesn't matter.
So common name is important. So this is where I would recommend you to use something that is an actual username that you want to use later on with your testing, whether you have an identity provider with your test username or things like that. So in my case, I will use one username I have in my Okta IdP that I will use later on. So I'm going to just use my Juniper email address. I'm going to copy it. We'll need to generate a private key, again, 4,000 bits.
We'll go to extensions, we'll select end entity. We'll click on subject, alternative name. Again, we'll just say copy common name. We'll go to key usage, will now need to select that this is a client certificate not the service certificate. And we will need key encipherments, digital signature, it should be OK. Now we click OK. We now have a client certificate.
So now we see there is a little dropdown in there. So we have a CA but now sign the client certificate. So now we have a CA and now we have a client certificate. What we'll do will need to export the CA. I will click on export. The CA cert, we are only exporting the public certificate, we are not touching the private key. Private Key stays untouched. It it is never exported anywhere. This is the only thing that protects the ownership of that certificate.
So we are exporting the private key in our test folder-- .mistCRT that's all we need. Click OK. The next thing we'll need is we'll need to export the certificate and the private key that we will use for client testing. Again, normally in production environment, you're not going to export private keys, they will be automatically pushed and distributed through MDM securely so they're never exposed to the network or anybody. But in our case, since we're testing, that's OK to do for now. So we'll click export.
In this case, the export format is pfx. That's the format that will include the client certificate, the client private key, and the CA cert in one package. So you can later on imported to one of your testing clients. And generally, this format is well understood by different operating systems.
It will ask you to encrypt that package. So just do a very secure password of 1234. Now we have to search, export it. We have a CA cert and we have a client cert. For now, this is good enough for our testin
CA 인증서를 추가하려면 다음을 수행합니다.
Juniper Mist Access Assurance에 의한 기본 서버 인증서 사용
Juniper Mist 클라우드는 Juniper Mist 클라우드에 추가된 각 조직에 대한 사설 CA(인증 기관) 역할을 합니다. Juniper Mist 서버 인증서를 발급합니다. 인증서가 구성되지 않은 경우 Juniper Mist 포털은 Juniper Mist CA에서 서명한 기본 서버 인증서를 클라이언트 디바이스에 제공합니다.
이름 auth.mist.com 에 대해 인증서가 발급되고 그림 2와 유사한 정보가 표시됩니다.
에서 발급한 서버 인증서
Juniper Mist 서버 인증서를 다운로드하려면 다음을 수행합니다.
사용자 지정 서버 인증서 사용
PKI가 이미 있고 기존 구성을 방해하지 않고 유지하려고 할 수 있습니다. 이러한 시나리오에서는 루트 CA의 공용 인증서와 Juniper Mist 포털에서 RADIUS 서버의 퍼블릭/프라이빗 키 쌍을 업로드해야 합니다.
RADIUS 서버가 각 클라이언트(서플리컨트)의 인증서를 검증할 수 있도록 클라이언트 디바이스도 동일한 인증서를 사용해야 합니다. 클라이언트의 현재 설정을 변경하지 않고 클라이언트가 인증서를 발급한 동일한 CA에서 발급한 서버 인증서를 신뢰하도록 하려면 이 작업을 수행합니다.
Juniper Mist 포털에 인증서를 업로드하려면 다음을 수행합니다.
Guidelines for using custom server certificates:
- Do not use a wildcard certificate, for example: *.abc.com for 802.1X authentication.
- You can use a certificate that contains a common name (CN) or a subject alternative name (SAN) for 802.1X authentication..
- We recommend the following x509 extension attributes. The majority of the client device operating systems support these extensions.
- Use certificate version 3 or v3 (not legacy v1)
- If the server name is being used as a validation criterion on the client side, then the certificate should include the SAN extension with the DNS name of the server.
- Include Extended Key Usage as a TLS web server authentication criterion (required for most Android devices).
이제 인증서 기반 인증 프로세스를 진행할 수 있습니다.





