I am having some difficulty understanding what it is you're trying to do. My point is, that since you have an existing ACS self-signed certificate operating on your ACS box(es), you don't need to generate a CSR to generate a new cert. Becauuse ACS (and ISE also) can generate self-sign certs for Admin and EAP purposes, these products provide the option to extend the lifetime of the cert. And that was what I was proposing. Because it doesn't require a CSR and it doesn't require any CA to sign the cert.
Were you planning to have your CSR signed by an external CA? Public or internal PKI?
My advice would be to forget about self-signed certtificates, and to look at getting a public signed certificate instead. It's the way of the future and unless you have configured your supplicants to only trust a certain RADIUS cert, you'd be better off with a public signed cert - at least for clients that run modern operating systems (Apple, Windows, Android). It means your https access to ACS will be without browser errors too. If your EAP clients are all specialised devices, then you need to check if they contain the Root CA, or have the ability to have a Root CA chain installed on them.
EAP clients (supplicants) don't care about the ACS/ISE EAP certificate's Subject and SAN fields. All they care about is whether they can trust it. And to be honest, supplicants should not be configured to contain the EAP certificate (unless it's a self signed cert of course) - it makes more sense to chose a CA to sign those certs, and to install the CA cert into supplicants - that will ensure that supplicants trust any cert issued by that CA.
Admin cert must contain the FQDN of the ACS node in the SAN fields, to avoid getting browser errors. Wildcard certs are acceptable for admin purposes.
It might help if you put some screen shots of the error you're getting. I don't use ACS and I don't recall what challenges one runs into with certificate creation.
