Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Use certificados digitais

Siga essas etapas para gerar e usar certificados para o servidor RADIUS que está integrado com o Juniper Mist Access Assurance para cada organização.

Ao usar a autenticação EAP, tanto o cliente quanto o servidor devem verificar a identidade um do outro. O cliente deve confiar no servidor com o qual está se comunicando, e o servidor deve autenticar o cliente. O certificado do servidor é a primeira etapa desse processo de autenticação mútua, e o cliente deve validar ou confiar nele antes de prosseguir com a comunicação.

Se dermos uma olhada em qualquer transação de EAP (por exemplo, EAP-TLS ou EAP-TTLS), independentemente de ser autenticação sem fio ou com fio, o primeiro passo é o servidor se identificar enviando uma mensagem de "Olá de servidor" para o dispositivo cliente.

Quando um dispositivo cliente recebe um certificado de servidor, ele analisa a lista de Autoridades de Certificados (CAs) confiáveis no perfil de Wi-Fi ou LAN e verifica se o certificado do servidor é assinado por um dos CAs confiáveis. Opcionalmente, se configurado, verifica se o nome do servidor corresponde à lista de nomes de servidor confiáveis na configuração do cliente.

Recomendamos não ignorar a etapa de validação e o certificado de servidor trust. Este é um risco de alta segurança e pode abrir ataques do MITM (Homem no meio).

Você pode usar um dos seguintes métodos para gerar e usar certificados para o servidor RADIUS integrado com o Juniper Mist Access Assurance para cada organização.

  • Certificado ca — a Juniper Mist exige certificados de CA específicos para estabelecer a confiança com seus dispositivos clientes. Esses certificados, emitidos por autoridades de certificados confiáveis (CAs), permitem que o Juniper Mist Access Assurance conceda acesso à rede aos dispositivos dos clientes. A validação dos dispositivos clientes pela Juniper Mist é baseada na apresentação de certificados pelos dispositivos, que devem ser assinados pelo mesmo CA.
  • Certificado de garantia de acesso da Juniper Mist padrão — a organização Mist mantém sua Autoridade de Certificados Mist (CA) exclusiva e privada responsável pela emissão do certificado de servidor do Access Assurance. Na ausência de configurações específicas, os clientes receberão um certificado padrão autenticado por seu respectivo Mist Org CA. Este certificado corresponde ao domínio "auth.mist.com".
  • Certificado de servidor personalizado — o certificado de servidor personalizado é favorecida quando você prefere não modificar a configuração atual do cliente, e deseja que os clientes confiem em certificados de servidor emitidos pela mesma Autoridade de Certificado (CA) que forneceu os certificados de cliente. Você deve inserir a chave privada e o Certificado assinado que você obteve do seu servidor RADIUS.

Leia os procedimentos a seguir para entender como usar os certificados acima.

Certificado de Autoridade de Certificado de Uso (CA)

Para que a autenticação baseada em certificados de protocolo de autenticação extensível — segurança de camada de transporte (EAP-TLS) funcione, você deve adicionar o certificado ca confiável no portal Juniper Mist.

Essa etapa permite que a Autenticação de acesso juniper Mist confie em certificados de clientes assinados por seus CAs adicionados.

Você pode obter o certificado de um CA externo. O CA pode ser um CA bem conhecido, público ou um CA empresarial.

Assista ao vídeo a seguir para saber como gerar um certificado para testes ou uso de laboratório:

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

Para adicionar um certificado de CA:

  1. No menu à esquerda do portal Juniper Mist, selecione Certificados de > de acesso da Organização >.
    A página Autoridades de certificados aparece exibindo uma lista de certificados.
  2. Clique em Adicionar autoridade de certificado.
  3. Cole seu certificado de CA no campo certificado assinado.
    Figura 1: Adicionar autoridade Add Certificate Authority de certificado

    O texto deve incluir as —–BEGIN CERTIFICATE—– linhas.—–END CERTIFICATE—–

    O sistema analisa e decodifica o certificado ca importado e exibe as propriedades do certificado nos termos do painel Propriedades . Recomendamos que você adicione seu ROOT CA, bem como todos os seus CAs intermediários ou certificados de emissão.

Use o certificado padrão de servidor pela Juniper Mist Access Assurance

A Juniper Mist Cloud atua como uma autoridade de certificado privado (CA) para cada organização adicionada na nuvem Juniper Mist. A Juniper Mist emite um certificado de servidor. Se nenhum certificado estiver configurado, o portal Juniper Mist apresenta um certificado de servidor padrão assinado pela Juniper Mist CA aos dispositivos clientes.

O certificado será emitido para o nome auth.mist.com e exibe as informações semelhantes às que você vê na Figura 2.

Figura 2: Certificado de servidor emitido pelo Mist Access Assurance Server Certificate Issued by Mist Access Assurance
Do lado do cliente, você deve configurar dispositivos clientes para confiar no certificado Mist CA e validar opcionalmente o nome do certificado de servidor conforme auth.mist.com.

Para baixar o certificado de servidor Juniper Mist:

  1. No menu à esquerda do portal Juniper Mist, selecione Certificados de > de acesso da Organização >.
    A página Autoridades de certificados aparece exibindo uma lista de certificados.
  2. Clique em Ver o certificado Mist.
    A tela exibe os detalhes do Certificado assinado . Copie o conteúdo do certificado no campo certificado assinado .
    Figura 3: Veja e copie o certificado View and Copy Mist Certificate Mist
  3. Armazene o conteúdo do certificado em sua máquina local e adicione a extensão .crt ou .cer no nome do arquivo. Por exemplo: mymistorgca.crt.
  4. Importe o arquivo do certificado para todos os seus dispositivos clientes como um certificado raiz confiável.

    Depois de configurar um dispositivo cliente para confiar no certificado Juniper Mist CA, você pode usar o certificado até que o certificado seja válido.

Use certificados de servidor personalizados

Você pode já ter um PKI e querer manter a configuração existente imperturbável. Nesse cenário, você deve enviar o certificado público do seu CA raiz e o par chave público/privado do servidor RADIUS no portal Juniper Mist.

Certifique-se de que seus dispositivos clientes também usem os mesmos certificados para que o servidor RADIUS valide o certificado de cada cliente (suplicante). Realize essa tarefa se quiser manter a configuração atual de seus clientes inalterada, e deseja que os clientes confiem no certificado de servidor emitido pela mesma CA que emitiu seus certificados.

Para enviar seu certificado ao portal Juniper Mist:

  1. No menu à esquerda do portal Juniper Mist, selecione Certificados de > de acesso da Organização >.
    A página aparece exibindo uma lista de certificados.
  2. Clique em Importar Certificado de raio personalizado para abrir a página do certificado.
    Figura 4: Importar certificado Import Custom RADIUS Server Certificate de servidor RADIUS personalizado
  3. Na página de certificado de servidor RADIUS personalizado de importação, digite os detalhes do seu certificado ca:
    Figura 5: Insira os detalhes Enter Custom Server Certificate Details do certificado do servidor personalizado
    • Chave privada — copie e cole as informações de chave privada. O texto deve incluir as BEGIN RSA PRIVATE KEY linhas.END RSA PRIVATE KEY
    • Senha de chave privada — digite a senha da chave privada (se disponível).
    • Certificado assinado — copie e cole o certificado como texto. Certifique-se de incluir todos os CAs intermediários e o certificado Root CA. O texto deve incluir as —–BEGIN CERTIFICATE—– linhas.—–END CERTIFICATE—–
  4. Clique em Salvar.
  5. Configure seus dispositivos de cliente para confiar na autoridade de certificado raiz (CA) que assinou seu certificado de servidor.
    Com essa etapa, você garante que ao atualizar ou alterar o certificado do servidor (que normalmente é feito todos os anos ou depois de alguns anos), os dispositivos clientes confiarão no novo certificado de servidor porque confiam no CA pai que o assinou.

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

Agora você pode avançar com o processo de autenticação baseado em certificados.