A CSR is a Certificate Signing Request and it is the first step of many steps in creating an X.509 certificate. When a CSR is created, the first thing that happens is that a private key is generated which is stored on the host that is generating the CSR. The premise is that the private key should stay on this host and never leave (because this is what is used to sign and encrypt its data). A public key is also generated but this is publicly visible in the certificate - the certificate itself is not a secret and is also publicly visible. The output that most users see from a CSR operation is a file containing a public key and some fundamental structure of the certificate that you want to create e.g. Subject, Organization etc. This CSR file is shipped off to the CA for certificate signing. The CA adds all the remaining stuff and bakes it into a signed certificate that the end user needs. However, the end user needs to combine that cert with their private key - in ISE, this process is when you 'bind' the cert to the CSR. Then the job is done.
Here are some easy steps to follow to create a certificate package that can be imported into a system without needing to generate a CSR on the end system itself (e.g. ISE or a WLC). Why would you need such a process? Well, some systems may not have the ability to create a CSR, or the CSR creation mechanism is not adequate enough. Or, your PKI organization doesn't want to process your device's CSR's, and rather generate the entire certificate using a corporate PKI tool chain.
Certificates contain a private key and a public key. The tricky part is the private key because it has to be created somewhere. In the ideal case, the private key should be created on the end device only, and NEVER leave that device. When you generate a CSR you're doing just that - you're creating a public and private key, but the private key stays on the box on which you generated the CSR.
But it is possible to create the private key off-box, and then import it into the end device later. And this is often required in cases, especially when you are in control of creating your own certs, sing your own PKI. If you're buying a public cert then ALWAYS send them a CSR - I don't think a public CA would even be allowed to generate a private key on behalf of its customers.
OpenSSL to the rescue
Anyway - we can solve this with openssl and some elbow grease ;-) The final output that we want is called a PCKS12 file, which contains the cert, the private key and any CA chain required.
High level tasks
Create private key with openssl (Linux/Windows - it doesn't matter)
Create a CSR using openssl with all the attributes you need (if you need SAN, then you need to create a config file)
Send the CSR to the PKI team to create the cert.
Once you have the cert, you need to package cert+privkey into a PKCS12 file, password protected.
Here is a worked example in Linux openssl (just substitute the filenames and contents as appropriate)
I created a san.cnf file that contained the data I needed for SAN - if you don't need a SAN then ignore this (in the case below, the only parts that need editing are the lines below the [alt_names] section - don't edit the stuff above it)
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
commonName = Common Name (e.g. server FQDN or YOUR name)
[ req_ext ]
subjectAltName = @alt_names
DNS.1 = ise01
DNS.2 = ise01.mydomain.com
IP.1 = 192.168.1.2
Get the CSR processed by the CA (that's a discussion for entire new thread - just pass this to a PKI admin who is in charge of generating the certificate from a CSR - it's not rocket science, but it cannot be simplified here). In my case the certificate was called ise01-cert-with-san.pem
The final resulting package is called ise01-final.pfx and this is password protected (the openssl will prompt for a password) - this is the file you should be able to import into your device. The private key and the public cert/key will be installed.