Hi @craiglebutt
If you (as the ISE admin) had nothing to do with this renewal, then I would be a bit worried, because for certs that are generated by public CA's, the private key should always be held by the customer (i.e. you). The way this is normally done for ISE, is to create a CSR (Cert Signing Request) on ISE - this act creates the private key and stores it safely in ISE. It also creates the public key and the signing request. That CSR file is sent to the CA. The CA has no knowledge of your private key. The CA creates the signed cert and hands you back a file. I suspect that the .crt file contains the signed cert and it would most likely be in DER (binary) format.
Here are some tips. Get hold of openssl (Windows/Linux/MAC) versions available and analyse the file. My first example shows the error that comes back when you don't specify the Input Format (-inform) of the file:
The other common input format is PEM. -inform pem
Even if you have a valid cert from your cert bloke, you still need the private key. Is it perhaps in ISE because someone else created the CSR without you knowing it? Have a look.
If that was a match, then click on the CSR and bind the .crt file to this request. If I recall, you may have to convert the .crt file to a PEM (text BASE64 encoded file) - openssl can easily do this with the -outform argument:
If however, your cert bloke has the private key in a separate file, then there is hope. Feed both files into the Cert import screen and then assign the cert to the correct portal tag - use the existing portal tag in your case. Remember that private key files are password protected.