Certificate Warnings during 802.1x

Certificate Warnings during 802.1x

Why am I getting a warning from my 802.1x supplicant about my RADIUS server certificate even though it was issued by a trusted CA?

All Environments

When a device configured for 802.1x begins the authentication process, it may receive an x509 certificate from the RADIUS server to identify itself to the device. This happens before the device has an IP address, so there can be no revocation status verification or DNS based verification as would be available during an HTTPS connection. There are only two criteria to protect the device from rogue RADIUS servers. The first one is the certificate trust chain and the second one is the subject name in the certificate being presented by the RADIUS server. 

Ideally, the 802.1x connection would be defined on the client device with a specific server name to look for in the RADIUS server certificate in addition to trusting the CA which issued the certificate. Without a server name defined in the 802.1x connection, ANY certificate issued by a CA could be trusted for this 802.1x session. This would present a major security risk since any certificate issued by a major 3rd party trusted CA could be used to put up a rogue RADIUS server. 

If an unsuspecting user were to connect to a rogue 802.1x service such as a wireless LAN which used EAP-PEAP with MSCHAP v2 for authentication, they would be susceptible to providing their password hash to an untrusted 3rd party simply because that party had a certificate issued by a public, trusted CA such as Verisign. 

In the absence of a named RADIUS server in the 802.1x configuration, some supplicants will provide the user with a pop up prompt to show the user of the device the certificate being supplied by the RADIUS server. It is up to the user to check the name on this certificate and make a decision on whether or not to trust this RADIUS server. 

To avoid the pop up warning, the 802.1x supplicant needs to be configured to trust a specific RADIUS server name. Instructions on how to do this vary from device to device. 

ClearPass Onboard performs this task during device registration to facilitate RADIUS connections without pop-up warnings to end users during 802.1x authentication.

ref:-https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Certificate-Warnings-during-802-1x/ta-p/176460

Windows Network Architecture and the OSI Model

The Microsoft Windows operating systems use a network architecture that is based on the seven-layer networking model developed by the International Standards Organization (ISO). Introduced in 1978, the ISO Open Systems Interconnection (OSI) Reference model describes networking as "a series of protocol layers with a specific set of functions allocated to each layer. Each layer offers specific services to higher layers while shielding these layers from the details of how the services are implemented. A well-defined interface between each pair of adjacent layers defines the services offered by the lower layer to the higher one and how those services are accessed." The following diagram illustrates the OSI reference model.

Microsoft Windows network drivers implement the bottom four layers of the OSI Reference Model:

Physical Layer
The physical layer is the lowest layer of the OSI model. This layer manages the reception and transmission of the unstructured raw bit stream over a physical medium. It describes the electrical/optical, mechanical, and functional interfaces to the physical medium. The physical layer carries the signals for all of the higher layers. In Windows, the physical layer is implemented by the network interface card (NIC), its transceiver, and the medium to which the NIC is attached.

Data Link Layer
The data link layer is further divided by Institute of Electrical and Electronics Engineers (IEEE) into two sublayers: logical link control (LLC) and media access control (MAC).

LLC

The LLC sublayer provides error-free transfer of data frames from one node to another. The LLC sublayer establishes and terminates logical links, controls frame flow, sequences frames, acknowledges frames, and retransmits unacknowledged frames. The LLC sublayer uses frame acknowledgement and retransmission to provide virtually error-free transmission over the link to the layers above.

MAC

The MAC sublayer manages access to the physical layer, checks frame errors, and manages address recognition of received frames.

In the Windows network architecture, the LLC sublayer is implemented in the transport driver, and the MAC sublayer is implemented in the NIC. The NIC is controlled by a software device driver called the miniport driver. Windows supports several variations of miniport drivers including WDM miniport drivers, miniport call managers (MCMs), and miniport intermediate drivers.

Network Layer The network layer controls the operation of the subnet. This layer determines the physical path that the data should take, based on the following:

• Network conditions.
• Priority of service.
• Other factors, such as routing, traffic control, frame fragmentation and reassembly, logical-to-physical address mapping, and usage accounting.

Transport Layer The transport layer ensures that messages are delivered error-free, in sequence, and with no loss or duplication. This layer relieves the higher-layer protocols from any concern with the transfer of data between them and their peers. A minimal transport layer is required in protocol stacks that include a reliable network or LLC sublayer that provides virtual circuit capability. For example, because the NetBEUI transport driver for Windows an OSI-compliant LLC sublayer, its transport layer functions are minimal. If the protocol stack does not include an LLC sublayer, and if the network layer is unreliable and/or supports datagrams (as with TCP/IP's IP layer or NWLink's IPX layer), the transport layer should include frame sequencing and acknowledgment, as well as retransmission of unacknowledged frames.

In the Windows network architecture, the LLC, network, and transport layers are implemented by software drivers known as protocol drivers, which are sometimes referred to as transport drivers.

Reference Link
+