Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

デジタル証明書を使用する

次の手順に従って、組織ごとに Juniper Mist Access Assurance と統合されている RADIUS サーバーの証明書を生成して使用します。

EAP 認証を使用する場合、クライアントとサーバーの両方が互いの ID を確認する必要があります。クライアントは通信相手のサーバーを信頼し、サーバーがクライアントを認証する必要があります。サーバー証明書は、この相互認証プロセスの最初のステップであり、クライアントは通信を続行する前に、サーバー証明書を検証または信頼する必要があります。

EAPトランザクション(EAP-TLSやEAP-TTLSなど)を見ると、無線認証か有線認証かに関係なく、最初のステップは、サーバーがクライアントデバイスに「Server Hello」メッセージを送信して自身を識別することです。

クライアントデバイスは、サーバー証明書を受信すると、Wi-FiまたはLANプロファイル内の信頼できる認証局(CA)のリストを参照し、サーバー証明書が信頼できるCAの1つによって署名されているかどうかを確認します。オプションで、構成されている場合は、サーバー名がクライアント構成内の信頼できるサーバー名のリストと一致するかどうかをチェックします。

検証手順と信頼サーバー証明書をバイパスしないことをお勧めします。これは高いセキュリティリスクであり、MITM(中間者)攻撃を開始する可能性があります。

以下のいずれかの方法を使用して、組織ごとに Juniper Mist Access Assurance と統合された RADIUS サーバーの証明書を生成して使用できます。

  • CA 証明書—Juniper Mist、クライアント デバイスとの信頼を確立するために特定のCA 証明が必要です。信頼できる認証局(CA)が発行するこれらの証明書により、Juniper Mist Access Assuranceはクライアントデバイスへのネットワークアクセスを許可できます。Juniper Mistによるクライアントデバイスの検証は、デバイスによる証明書の提示に基づいており、同じCAによって署名される必要があります。
  • Default Juniper Mist Access Assurance Certificate—Mist組織は、Access Assuranceサーバー証明書の発行を担当する、独自のプライベートなMist認証局(CA)を維持しています。特定の設定がない場合、クライアントはそれぞれのMist組織CAによって認証されたデフォルトの証明書を受け取ります。この証明書は、ドメイン「auth.mist.com」に対応します。
  • [カスタム サーバー証明(Custom )]:現在のクライアント設定を変更せず、クライアント証明書を提供したのと同じ認証局(CA)が発行したサーバ証明書をクライアントが信頼するようにしたい場合に、カスタム サーバ証明書が優先されます。RADIUSサーバーから取得した秘密キーと署名付き証明書を入力する必要があります。

上記の証明書の使用方法を理解するには、次の手順をお読みください。

認証局(CA)証明書を使用

拡張認証プロトコルトランスポート層 セキュリティ (EAP-TLS) 証明書ベースの認証を機能させるには、Juniper Mist ポータルで信頼できる CA 証明書を追加する必要があります。

この手順により、Juniper Mist アクセス認証は、追加した 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 証明書を追加するには、次の手順を実行します。

  1. Juniper Mist ポータルの左側のメニューから、 [Organization > Access > Certificates](組織アクセス証明書) を選択します。
    [認証局(Certificate Authorities)] ページが表示され、証明書のリストが表示されます。
  2. [Add Certificate Authority] をクリックします。
  3. CA 証明書を [署名付き証明書] フィールドに貼り付けます。
    図 1: 認証局Add Certificate Authorityの追加

    テキストには、 —–BEGIN CERTIFICATE—– 行と —–END CERTIFICATE—– 行を含める必要があります。

    システムは、インポートされた CA 証明書を解析してデコードし、証明書のプロパティを [プロパティ ] ペインに表示します。ルート CA だけでなく、すべての中間 CA または証明書の発行も追加することをお勧めします。

Juniper Mist Access Assuranceによるデフォルトサーバー証明を使用

Juniper Mistクラウドは、Juniper Mistクラウドに追加された各組織のプライベート認証局(CA)として機能します。Juniper Mist はサーバー証明書を発行します。証明書が構成されていない場合、Juniper Mistポータルは、CAによって署名されたデフォルトのサーバー証明書Juniper Mistクライアントデバイスに提示します。

名前 auth.mist.com に対して証明書が発行され、 図 2 に示すような情報が表示されます。

図2:Mist Access AssuranceServer Certificate Issued by Mist Access Assurance発行のサーバー証明
クライアント側では、Mist CA 証明書を信頼し、必要に応じてサーバー証明書名を auth.mist.com として検証するようにクライアントデバイスを構成する必要があります。

Juniper Mistサーバー証明書をダウンロードするには:

  1. ポータルJuniper Mist左側のメニューから、 [Organization > Access > Certificates](組織アクセス証明書) を選択します。
    [認証局(Certificate Authorities)] ページが表示され、証明書のリストが表示されます。
  2. [View Mist Certificate] をクリックします。
    画面に 署名済み証明書 の詳細が表示されます。[ 署名付き証明書(Signed Certificate )] フィールドから証明書の内容をコピーします。
    図 3: 証明書View and Copy Mist Certificateの表示とコピー Mist
  3. 証明書の内容をローカル コンピューターに格納し、ファイル名に拡張子 .crt または .cer を追加します。たとえば、mymistorgca.crt です。
  4. 証明書ファイルを信頼されたルート証明書としてすべてのクライアントデバイスにインポートします。

    Juniper Mist CA証明書を信頼するようにクライアントデバイスを構成すると、証明書が有効になるまでその証明書を使用できます。

カスタムサーバー証明書を使用する

すでに PKI があり、既存の設定をそのままにしておきたい場合があります。このようなシナリオでは、ルート CA の公開証明書と RADIUS サーバーの公開/秘密キーのペアを Juniper Mist ポータルにアップロードする必要があります。

RADIUSサーバーが各クライアント(サプリカント)の証明書を検証するように、クライアントデバイスも同じ証明書を使用していることを確認してください。このタスクは、クライアントの現在の設定を変更せずに、証明書を発行したのと同じ CA によって発行されたサーバー証明書をクライアントが信頼するようにする場合に実行します。

証明書を Juniper Mist ポータルにアップロードするには、次の手順を実行します。

  1. ポータルJuniper Mist左側のメニューから、 [Organization > Access > Certificates](組織アクセス証明書) を選択します。
    ページが表示され、証明書のリストが表示されます。
  2. [Import Custom Radius Certificate] をクリックして、証明書ページを開きます。
    図4:カスタムRADIUSサーバー証明Import Custom RADIUS Server Certificateのインポート
  3. [カスタム RADIUS サーバー証明のインポート] ページで、CA 証明書の詳細を入力します。
    図 5: カスタム サーバー証明 の詳細Enter Custom Server Certificate Detailsの入力
    • [秘密キー(Private Key)]:秘密キー情報をコピーして貼り付けます。テキストには、 BEGIN RSA PRIVATE KEY 行と END RSA PRIVATE KEY 行を含める必要があります。
    • [秘密キーのパスワード(Private Key Password)]:秘密キーのパスフレーズを入力します(使用可能な場合)。
    • [署名付き証明書(Signed Certificate)]:証明書をテキストとしてコピー&ペーストします。すべての中間 CA とルート CA 証明書が含まれていることを確認します。テキストには、 —–BEGIN CERTIFICATE—– 行と —–END CERTIFICATE—– 行を含める必要があります。
  4. 保存」をクリックします。
  5. サーバー証明書に署名したルート証明機関 (CA) を信頼するようにクライアントデバイスを設定します。
    この手順では、サーバー証明書を更新または変更するとき (通常は毎年または数年後に行われます)、クライアント デバイスは署名した親 CA を信頼するため、新しいサーバー証明書を信頼するようにします。

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).

これで、証明書ベースの認証プロセスを進めることができます。