> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/pt/portal-de-administracao/settings/settings-server.md). # Configurações do servidor ## Portas & Endereços IP ### Visão geral A RADIUSaaS opera um serviço RadSec para fornecer autenticação segura baseada na nuvem aos seus utilizadores. Além disso, para os clientes que não conseguem utilizar RadSec no seu ambiente de rede, por exemplo, devido a limitações de hardware e software, a RADIUSaaS fornece proxies RADIUS, que tratam da conversão de protocolo de RADIUS para RadSec. Tanto o serviço RadSec como o RADIUS oferecem um endereço IP público que permite aos seus dispositivos e serviços de rede comunicar com o nosso serviço a partir de qualquer lugar via internet. Estes serviços operam nas suas portas registadas exclusivas. ## RadSec / TCP
#### **DNS do RadSec** A entrada 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 o RadSec: 2083 ### Failover & Redundância Nos casos em que os clientes necessitam de níveis mais elevados de redundância, podem ser configurados múltiplos endpoints RadSec para a sua instância, fornecendo endereços IP adicionais. Note que existe um custo adicional para este serviço.
{% hint style="info" %} É importante notar que a 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 avançará 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 múltiplos servidores RadSec por ordem de prioridade (Meraki).

## Definições do RadSec ### Versão máxima do TLS Esta definição controla a versão máxima do TLS para a sua **interface RadSec**. A versão mínima está fixada em 1.2, o máximo predefinido está definido em 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 a definição de verificações de revogação para certificados RadSec discutida a seguir. ### Versão máxima do EAP TLS Esta definição controla a versão máxima do TLS utilizada com EAP quando os seus endpoints se autenticam na sua instância RADIUSaaS usando um certificado (EAP-TLS) ou [credenciais de nome de utilizador/palavra-passe](/pt/portal-de-administracao/usuarios/users.md#protocols). Para todos os sistemas operativos modernos, **o TLS 1.3 é o predefinido recomendado**. No entanto, algumas compilações mais antigas do Windows 10/11 anunciavam suporte a TLS 1.3 para EAP-TLS com uma implementação não conforme. Se clientes Windows nas compilações afetadas apresentarem problemas de conectividade, limite a versão do protocolo negociada a TLS 1.2 para uma compatibilidade mais ampla. ### 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 do utilizado para certificados de autenticação do cliente. {% endhint %} Para o funcionamento correto 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 normalmente utilizam TLS mútuo (mTLS), em que ambos os pares se autenticam mutuamente usando certificados X.509 durante o handshake TLS. A implementação da RADIUSaaS impõe mTLS. Para determinar a validade e o estado de revogação de um certificado cliente RadSec, o certificado tem de ser apresentado pelo cliente como parte do processo de autenticação TLS. Só depois de o certificado ser recebido podem ser efetuadas 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 `CertificateRequest`, `Certificate`, e `CertificateVerify` mensagens. Quando a autenticação do cliente é necessária e corretamente aplicada, o certificado 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 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 mitigar o comportamento acima, a **Verificação de revogação para certificados RadSec** definição é desativada quando a versão máxima do TLS é definida como 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 do cliente é solicitada, o certificado cliente RadSec é trocado como parte do handshake inicial e validado antes de a ligação TLS ser estabelecida.\ Isto permite ao servidor RadSec verificar imediatamente o certificado do cliente, incluindo o seu estado de revogação, e fazer falhar 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 do TLS é definida como 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, por isso, escutam nas portas 1812/1813.
### **Endereços IP do Servidor e Localização** {% hint style="warning" %} Estes endereços IP apenas escutam em [RADIUS](/pt/overview.md#what-is-radius) sobre as portas UDP 1812/1813. {% endhint %} Geolocalizaçã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 dos 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 & 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 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 ### CA do cliente Por predefinição, a 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 **CA do cliente**. A CA do cliente é única para cada cliente. Para criar a sua CA do cliente, siga estes passos simples: 1. Navegue até **Definições** > **Definições do Servidor** 2. Clique em **Adicionar** 3. Escolha **Deixe 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 **CA do cliente**, 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 seu portal web SCEPman Certificate Master. 2. Selecione Request Certificate à esquerda 3. Selecione **Servidor (Web)** 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 quiser. 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 **Autenticação do Servidor e do Cliente** para o EKU. 9. **Submeter** 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 seu certificado de servidor criado nos passos acima, navegue até **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 seu ficheiro de certificado ou clique para 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 quiser alterar isto, consulte a [documentação](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 de serviço. {% endhint %} Como os certificados expiram periodicamente ou a sua preferência sobre quais certificados pretende usar pode mudar, é importante que possa controlar o certificado que o seu servidor está a usar. A **Ativo** coluna mostra-lhe o certificado que o seu servidor está atualmente a usar. Para alterar o certificado que o seu servidor está a usar, 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 da CA** no topo. Isto descarregará diretamente a **CA raiz de confiança** do **ativo** certificado de servidor. 2. Clique no **descarregar** ícone na linha correspondente.
**Opção 2** abrirá uma caixa de diálogo que mostra 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 é codificado em base64 (PEM). Caso o seu dispositivo (por ex., controlador WiFi) precise 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 periodicamente. Cinco meses antes de o seu certificado expirar, o seu painel dará uma indicação, exibindo um sinal de aviso ao lado dele. ![Captura de ecrã que mostra a expiração do certificado](/files/b21ebe5c8681260acc22588dbfd8b0e4987ac05c) Se o triângulo for exibido 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 %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.radiusaas.com/pt/portal-de-administracao/settings/settings-server.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.