# Definições do Servidor ## Portas e Endereços IP ### Visão geral RADIUSaaS opera um serviço RadSec para fornecer autenticação segura baseada na nuvem aos seus utilizadores. Além disso, para aqueles clientes que não conseguem utilizar RadSec no seu ambiente de rede, por exemplo, devido a limitações de hardware e software, o RADIUSaaS fornece Proxies RADIUS, que tratam da conversão do protocolo de RADIUS para RadSec. Tanto o serviço RadSec como o serviço RADIUS oferecem um endereço IP público que permite que os seus dispositivos e serviços de rede comuniquem com o nosso serviço a partir de qualquer lugar via internet. Estes serviços operam nas suas portas registadas exclusivas. ## RadSec / TCP

A mostrar IP e porta do RadSec

#### **DNS do RadSec** A entrada de DNS através da qual o serviço RadSec pode ser alcançado. #### **Endereços IP do servidor** Este é o endereço IP público do serviço RadSec. #### **Portas do RadSec** Esta é a porta registada para RadSec: 2083 ### Failover e Redundância Nos casos em que os clientes necessitam de níveis mais elevados de redundância, podem ser configurados vários endpoints RadSec para a sua instância, fornecendo endereços IP adicionais. Note que existe um custo adicional para este serviço.

A mostrar dois endereços IP públicos, um para cada um dos serviços RadSec.

{% hint style="info" %} É importante notar que o RADIUSaaS **NÃO fornece failover** entre endpoints RadSec. Em vez disso, este failover é normalmente implementado no seu equipamento de rede, como mostrado no exemplo abaixo usando Meraki. Recomenda-se configurar o seu cenário de failover usando endereços IP em vez de DNS para melhor visibilidade e menor dependência de um serviço adicional (DNS). {% endhint %} Nesta configuração, os dois endereços IP RadSec são listados por ordem de preferência. Quando o Meraki não consegue alcançar um dos endereços IP, normalmente tentará mais duas vezes e passará para o seguinte. Para mais informações sobre a capacidade de failover do seu sistema Meraki (ou outro), consulte os seus próprios recursos.

A mostrar vários servidores RadSec por ordem de prioridade (Meraki).

## Definições do RadSec {% hint style="info" %} As definições seguintes controlam determinados aspetos da ligação RadSec à sua instância RADIUSaaS. {% endhint %} ### Versão Máxima de TLS Esta definição controla a versão máxima de TLS para a sua interface RadSec. A versão mínima está fixa em 1.2 e o máximo predefinido está definido para 1.3. O TLS 1.3 oferece várias vantagens em relação ao 1.2, incluindo o mecanismo de autenticação pós-handshake, que permite solicitar credenciais adicionais antes de concluir o handshake. Isto é importante para as verificações de validação da definição de certificados RadSec discutida a seguir. ### Verificação de Revogação para Certificados RadSec {% hint style="info" %} Esta definição determina se deve ser efetuada uma verificação de revogação para todas as ligações RadSec. O método de verificação da revogação difere ligeiramente daquele usado para certificados de autenticação de cliente. {% endhint %} Para o funcionamento adequado do RadSec, dispositivos de rede como Access Points, Switches e Servidores VPN estabelecem uma ligação protegida por TLS ao servidor RadSec. As implementações RadSec utilizam normalmente TLS mútuo (mTLS), em que ambos os pares se autenticam mutuamente usando certificados X.509 durante o handshake TLS. A implementação RADIUSaaS impõe mTLS. Para determinar a validade e o estado de revogação de um certificado de cliente RadSec, o certificado deve ser apresentado pelo cliente como parte do processo de autenticação TLS. Só depois de o certificado ser recebido podem ser realizadas verificações de revogação (por exemplo, via CRL ou OCSP). #### **TLS 1.2** O TLS 1.2 suporta autenticação TLS mútua durante o handshake inicial usando as mensagens `CertificateRequest`, `Certificate`, e `CertificateVerify` Quando a autenticação de cliente é exigida e corretamente aplicada, o certificado de cliente RadSec é apresentado, validado e verificado quanto à revogação antes de a sessão TLS ser estabelecida e antes de qualquer tráfego RADIUS ser trocado. \ No entanto, o TLS 1.2 também permite autenticação opcional do cliente e suporta renegociação. Como resultado, algumas implementações de cliente RadSec podem concluir o handshake inicial sem apresentar um certificado de cliente. Este comportamento é específico da implementação e não uma limitação do protocolo TLS 1.2. {% hint style="info" %} Para atenuar o comportamento acima, a **Verificação de Revogação para Certificados RadSec** definição é desativada quando a versão máxima de TLS é definida para 1.2. Note que pode reativá-la manualmente mais tarde. {% endhint %} #### **TLS 1.3** O TLS 1.3 fornece um modelo mais determinístico e simplificado para autenticação TLS mútua. Quando a autenticação de cliente é solicitada, o certificado de cliente RadSec é trocado como parte do handshake inicial e validado antes de a ligação TLS ser estabelecida.\ Isto permite que o servidor RadSec verifique imediatamente o certificado do cliente, incluindo o seu estado de revogação, e que falhe o handshake se o certificado for inválido ou revogado. Como resultado, o TLS 1.3 permite uma aplicação mais rigorosa e previsível da autenticação TLS mútua para ligações RadSec. {% hint style="info" %} A **Verificação de Revogação para Certificados RadSec** definição é ativada automaticamente quando a versão máxima de TLS é definida para 1.3. {% endhint %}
## RADIUS / UDP Esta secção está disponível quando tiver configurado pelo menos um [Proxy RADIUS](/pt/portal-de-administracao/settings/settings-proxy.md). Para cada proxy, está disponível um endereço IP público separado. Os endereços IP públicos nesta secção suportam apenas o protocolo RADIUS e, portanto, escutam nas portas 1812/1813.
### **Endereços IP e Localização do Servidor** {% hint style="warning" %} Estes endereços IP apenas escutam em [RADIUS](/pt/details.md#what-is-radius) sobre as portas UDP 1812/1813. {% endhint %} Geo-localização do(s) Proxy/Proxies RADIUS, bem como o(s) respetivo(s) endereço(s) IP público(s). ### **Segredos Partilhados** O segredo partilhado para o respetivo Proxy RADIUS. Por predefinição, todos os Proxies RADIUS são inicializados com o mesmo segredo partilhado.

A mostrar alteração de segredos partilhados por proxy

### **Portas** Esta secção apresenta as portas padrão para os serviços de autenticação RADIUS (1812) e contabilização RADIUS (1813). ### **Failover e Redundância** #### Redundância do Proxy Note que um único Proxy RADIUSaaS não fornece redundância. Para garantir redundância, configure vários Proxies RADIUSaaS conforme descrito [aqui](/pt/portal-de-administracao/settings/settings-proxy.md#load-balancing). #### Redundância do Serviço RadSec para Proxies Ao usar o RADIUSaaS com várias instâncias RadSec, os Proxies são configurados automaticamente para se ligarem a todas as instâncias RadSec disponíveis. Um Proxy RADIUSaaS dará prioridade à ligação ao serviço RadSec regional mais próximo. Se esse serviço não estiver disponível, mudará para outro Serviço RadSec disponível. ## Certificados do Servidor ### Customer-CA Por predefinição, o RADIUSaaS gera um **Certificado de Servidor RADIUS** assinado por uma Autoridade de Certificação (CA) que está disponível no nosso serviço apenas para este propósito específico. Chamamos-lhe **Customer-CA**. A Customer-CA é única para cada cliente. Para criar a sua Customer-CA, siga estes passos simples: 1. Navegue para **Definições** > **Definições do Servidor** 2. Clique em **Adicionar** 3. Escolha **Deixar o RaaS criar uma CA para si** 4. Clique em **Guardar** 5. Após a criação, verá um novo certificado disponível em Certificados do Servidor
### Traga o seu próprio certificado Caso não queira usar a **Customer CA**, pode carregar até dois dos seus próprios certificados. #### Certificado de servidor emitido pelo SCEPman Siga estes passos para utilizar o SCEPman Certificate Master para gerar um novo certificado de servidor: 1. Navegue até ao portal Web do seu SCEPman Certificate Master. 2. Selecione Request Certificate à esquerda 3. Selecione **(Web) Server** no topo 4. Selecione **Formulário** 5. Introduza todos os Subject Alternative Names (SANs) para os quais o certificado deverá ser válido, separados por vírgulas, pontos e vírgulas ou quebras de linha. Gere um certificado de servidor conforme descrito [aqui](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) e forneça qualquer FQDN que pretenda. Recomendamos adaptar o SAN do certificado de servidor predefinido, por exemplo, `radsec-.radius-as-a-service.com`. 6. Defina o **Formato do ficheiro de download** para **PEM** 7. Selecione **Incluir Cadeia de Certificados** e descarregue o certificado. 8. Certifique-se de incluir **tanto Autenticação de Servidor como de Cliente** para o EKU. 9. **Submeta** o pedido para descarregar o novo certificado de servidor. {% hint style="warning" %} **Importante**: Tome nota temporária da palavra-passe, uma vez que não pode ser recuperada do Certificate Master. {% endhint %}
### Carregue o novo certificado de servidor para **RADIUSaaS** Para adicionar o certificado de servidor criado nos passos acima, navegue para **instância RADIUSaaS** > **Definições** > **Definições do Servidor** > **Adicionar,** depois 1. Escolha **Certificado codificado em PEM ou PKCS#12** (Se selecionou PKCS#12 no passo 5, isto contém a chave pública e privada) 2. Arraste e largue o ficheiro do seu certificado ou clique para o procurar 3. Introduza a palavra-passe da sua **Chave Privada** 4. Clique em **Guardar**
{% hint style="info" %} Note que: Por predefinição, o SCEPman Certificate Master emite certificados válidos por 730 dias. Se pretender alterar isto, consulte a [documentação do SCEPman](https://docs.scepman.com/advanced-configuration/application-settings/certificates#appconfig-validityperioddays). {% endhint %} ### Ativação do certificado {% hint style="warning" %} Certifique-se de monitorizar a expiração do seu certificado de servidor e renová-lo atempadamente para evitar interrupções do serviço. {% endhint %} Como os certificados expiram de tempos a tempos ou a sua preferência sobre quais certificados pretende usar muda, é importante que possa controlar o certificado que o seu servidor está a utilizar. A **Ativo** coluna mostra-lhe o certificado que o seu servidor está atualmente a utilizar. Para alterar o certificado que o seu servidor está a utilizar, expanda a linha do certificado que pretende escolher e clique em **Ativar**. ### Descarregar Para descarregar o seu **Certificado de Servidor,** tem duas opções: 1. Clique em **Descarregar Certificado CA** no topo. Isto irá descarregar diretamente a **CA raiz de confiança** do certificado de servidor **ativo** atualmente. 2. Clique no **ícone de descarga** na linha correspondente.
**A Opção 2** abrirá uma caixa de diálogo mostrando o caminho completo do certificado. O **certificado raiz** será sempre marcado a verde.

A mostrar o certificado raiz a verde

Para ambas as opções, o certificado raiz descarregado está codificado em base64 (PEM). Caso o seu dispositivo (por exemplo, controlador WiFi) necessite de uma codificação binária (DER), pode convertê-lo usando [OpenSSL](https://openssl.org/): ```sh openssl x509 -inform pem -in -outform der -out ``` ### Eliminar Para eliminar um certificado, expanda a linha correspondente, clique em **Eliminar** e confirme a sua escolha. ### Expiração do Certificado {% hint style="danger" %} Não deixe expirar o Certificado de Servidor RADIUS. Isso quebrará a autenticação. {% endhint %} Os certificados expiram de tempos a tempos. Cinco meses antes de o seu certificado expirar, o seu painel irá dar-lhe um aviso ao apresentar um sinal de alerta ao lado dele. ![Captura de ecrã a mostrar a expiração do certificado](/files/b21ebe5c8681260acc22588dbfd8b0e4987ac05c) Se o triângulo for apresentado ao lado do Certificado de Servidor RADIUS ativo, siga este guia para o atualizar: {% content-ref url="/pages/4e7be4fd070b104be786df92906347a077e28561" %} [Renovação do Certificado do Servidor](/pt/configuracao/renew-certificate.md) {% endcontent-ref %} ## Ligação SCEPman {% hint style="warning" %} Apenas SCEPman Enterprise Edition Aplicável à versão 3.0 e superior {% endhint %} A definição SCEPman Connection foi concebida para ligar diretamente a sua instância RaaS à sua instância SCEPman. Quando configurar esta ligação, o RaaS executará a seguinte tarefa: 1. Criar e ativar um novo Certificado de Servidor 2. Irá gerir este certificado de servidor, incluindo o processo de renovação.
#### Para estabelecer esta ligação, siga estes passos: 1. Copie o token da API mostrado. 2. Navegue até ao seu SCEPman App Service conforme [este](https://docs.scepman.com/scepman-configuration/application-settings#convenient-configuration-in-the-app-service-configuration) guia e crie uma nova variável de ambiente chamada [AppConfig:RADIUSaaSValidation:Token](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/radiusaas) usando o token anteriormente copiado como valor. 3. Aplique as suas definições e reinicie o seu App Service. 4. Introduza o URL da sua instância SCEPman no campo SCEPman URL.
5. Clique em **Configurar Ligação**. Esta ação desativa o certificado de servidor atual para que o certificado recém-criado possa ser gerido. 6. Após a conclusão da configuração, aparecerão dois novos botões que substituirão os anteriores.
1. **Rodar Certificado**. Este botão irá rodar e ativar o seu certificado de servidor entre os dois espaços disponíveis. *Servercertificate-**upload0*** e *Servercertificate-**upload1***. 2. **Eliminar Ligação.** Este botão eliminará a ligação configurada anteriormente. Note que esta ação não pode ser desfeita. Quando eliminar a ligação, o token também será eliminado. Caso pretenda configurar a ligação mais tarde, terá de seguir novamente os passos acima. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/pt/portal-de-administracao/settings/settings-server.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.