A quick thought here: If you are using a config profile and make any changes when you go to apply the changes the device will remove the "old" profile and install the "new". If your config profile has wifi settings this means that the wifi config profile has been removed and there is no longer a method of connecting to the network and installing the new config profile unless you connect using a cable. Does this sound like a possibility or am I going the wrong direction with this?

To remove the old WiFi Profile we have been connecting to a guest network so the JSS can send the new one,
I have changed nothing in the profile except updating the certificate.
The rest of our macs that aren't using AD had this issue too, but the solution was to go into the Keychain and delete all certs relating to "ise" and "DigiCert", except under System Certificates. I only use this profile on our lab laptops so students can login through AD, thus the problem is isolated to those machines only. What seems to be happening is at the login window it's not actually able to connect to the network anymore.

If you delete the certificates and connect to the network manually, it will then download the new certificates and everything is fine. If you push the Configuration Profile with the certificate, it fails to connect.

You have an excellent process set up with your secondary wireless connection to make modifications! I don't see anything wrong with the settings in your config profile. When you got the new cert, did you edit the old config profile or create a new one with your new certs? I have had issues in the past with editing a profile vs creating a new one. Have you already tried removing the wifi and old cert profile and replacing it with a brand new built from ground up wifi and cert config profile?

I have reimaged a machine just for debugging this, glad I didn't reimage one of the lab ones that is having the same problem.
I did create a brand new policy too.
Basically it just has the "ISE" cert and settings for the WiFi network. We changed providers so the CA has changed. That CA is not included in the System Roots store, which I suspect is the problem, but even when pushing these as well it still gives the same

When connecting manually however, everything seems to work without a hitch. The "Login" keychain for "Certificates" was empty excluding the JSS cert, until accepting the "ISE" cert for WiFi. the keychain is then populated as so

I have tried deploying all of these certificates through a configuration profile with still no success.
It all works PERFECTLY when you manually connect, but when you do it this way, AD users cannot login because there is no WiFi at the login window.

I believe your certs need to be in the same payload as your wireless settings and you need to go to the Trust tab in the Network payload and trust those certs. Also, you may want to try EAP-TLS instead of PEAP.

@cbrewer

Adding the network certificate to the Trust option resolved this issue. Thank you much!