ISE Portal not working after new Certificate

[Andreas Hoffmann]

I am trying to replace the web certificate used for the Guest portal of my ISE ver 2.1.0.474; the current certificate was issued by the now deprecated StartSSL CA and thus needs to be replaced.

I generated a CSR with the valid domain name, exported it, and had it signed by a CA - with success.

I did a "bind certificate" - with success.

I edited the certifocate to select "Portal" as usage (with the Default = only group) - with success, that is: I accept the "portal will restart" message and after a few seconds, a toaster message that the certificate was successfully installed appears.

However, the portal is not working afterwards. Apparently, the web server restart does not work (nmap reports the port as closed). Switching back to the previous cert makes it work again.

What is wrong here?

Remark: The intermediate (Lets Encrypt X3) was already among the "Trusted Certificates"beforeI generated the CSR.

[Mohammed al Baqari]

Hi,

When you import the CA cert in trusted certificates, did you enable 'Trust for authentication of Cisco Services'.

Also, when you import the certificate did you select the usage as portal

[Andreas Hoffmann]

Thank you,

1) No. I checked only "Trust for authentication witinISE", which is the same setting as with the (working) intrmediate of StartCom. I now added "Trust for client authentication and Syslog" and "Trust for authentication of Cisco Services". -- Did not help

2) I generated the CSR as "Multi-Use". During the import itself, I checked no use; instead, I added the intended uses one by one afterwards via "Edit"

[Mohammed al Baqari]

After importing the cert, post the output of show application status ise.

[Andreas Hoffmann]

See below for the output of sho application status ise.

This does not change when I switch certificates. However, the output of sho ports | i 443  does change (below you see the output with a working cert, with the letsencrypt cert there is no ::8443 entry)

In order to be able to make the above output, I had to be somewhat brutal and reset the locked-out cli admin password from a DVD boot. Since that reboot, the behaviour has changed a bit additionally: When changing portal certificates in the GUI to anything but the default self-signed certificate, I get a message "Internal error. Ask your system administrator to check the logs for more details." (but the cert switch (or in case of the LE cert: disabling the server) does occur nevertheless)

So I am asking myself to check the logs for more details, but I do not know what to look for ...

[ajc]

I probably know about the problem you are having. I need the following from you:

1.-Provide an screenshot of the trusted certificate list.

2.-Provide an screenshot of the system certificates (I need to validate something)

3.-Go to WORK CENTER --- > GUEST ACCESS --- > PORTALS AND COMPONENTS --- > GUEST PORTALS --- > Select your portal --- > PORTAL TEST URL (Send me the result).

I think you are hitting the same bug I had before but the information above is needed for validation purposes. Omit/Remove any sensitive data.

thanks

[Andreas Hoffmann]

---

@ajc wrote:

I probably know about the problem you are having. I need the following from you:

1.-Provide an screenshot of the trusted certificate list.

2.-Provide an screenshot of the system certificates (I need to validate something)

3.-Go to WORK CENTER --- > GUEST ACCESS --- > PORTALS AND COMPONENTS --- > GUEST PORTALS --- > Select your portal --- > PORTAL TEST URL (Send me the result).

I think you are hitting the same bug I had before but the information above is needed for validation purposes. Omit/Remove any sensitive data.

thanks

---

For 1 and 2, see attached screenshots.

Note that I meanwhile managed to activate the desired certificate by stopping and starting the application from the CLI, but of course it would be better if things worked more out of the box next time ...

For 3, the portal test url url https://10.0.1.239:8443/portal/PortalSetup.action?portal=051c1a90-ce8c-11e6-b0bf-0050568a0002 is reported as SSL_ERROR_BAD_CERT_DOMAIN because the now active letsencrypt cert is of course issued to the name and not to the ip, so this is expected behaviour; the test displays correctly after making the browser ignore the problem, and it also works correctly when invoking the portal with the official url.

Thanks

[ajc]

Let's start,

I am almost sure you are facing the following bug.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCut16630

Basically you need the PORTALS and ADMIN Cert on the same signed cert (I am using an Entrust Public signed cert for this so the sponsor portal, guest portal - WLC URL Redirect for WebAuth, hotspot  portal, etc can actually work properly. SEE ATTACHED SCREENSHOT.

***IMPORTANT****: BEFORE JOINING BOTH SERVICES IN THE SAME CERT, YOU MUST TO CHECK IF THERE IS SOMETHING WRONG WITH THE CERTIFICATE DB ON ISE AS MENTIONED NEXT. It is possible that you will need to change portal tag and recreate it.

2nd and most important issue. IF YOU HAVE an intermediate or root cert in the TRUSTED CERTIFICATE LIST of ISE with the SAME Common Name (CN) - no matter the serial number is different, the Internal ISE Certificate DB gets corrupted and you will need additional instructions I can provide you to fix it.

[ajc]

Additional screenshots about certificate configuration and portals. IT IS PROBABLY necessary that you need to recreate the PORTAL TAG if you are using it

[ajc]

Question,

Based on my understanding, you were using starcom certificates before and replaced them with the let's encrypt x3. When you replaced the certs, the application services are restarted. SO if you were using before one of the following highlighted certs and BOTH with the same CN, then it is quite possible your internal Cert DB is corrupted but it can be easily fixed. Please confirm if both certs has the same CN (posts an screenshot with the CN displayed for both).

[Andreas Hoffmann]

The upper certificate (serial number 3F AD 7F D6 A9 BF B8 3A) has

subject = CN=StartCom Certification Authority G3,O=StartCom CA,C=ES

issuer = CN=StartCom Certification Authority G3,O=StartCom CA,C=ES

valid = Wed, 22 Mar 2017 07:19:56 UTC -- Sat, 22 Mar 2042 07:17:58 UTC

The second certificate (serial number 32 11 E0 6C 2D 8C 9A 39 86 8F 40 60 78 3C B6 01) has

subject = CN=StartCom Certification Authority G3,O=StartCom CA,C=ES

issuer = CN=StartCom Certification Authority,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL

valid = Tue, 11 Apr 2017 07:30:01 UTC -- Mon, 11 Apr 2022 07:30:01 UTC

So in spite of different issuers etc., the subjects are indeed identical, as you suspected ...

If this means the Cert DB is corrupted, how can it be fixed? Since they are obsolete, it wouldn't be a problem if we remove all StartCom certs in doing so.

[ajc]

Hi Andreas,

What you sent me confirms you are hitting a known bug.

The "INTERNAL ERROR CONTACT ADMINISTRATOR" error message is directly related to the Certificate DB corruption even though you are not currently using those starcom certs. That affects your regular portal operation and could require to reconfigure the certificate portal tag as well. I will provide you with instructions as I fixed it by myself.

On the other hand, Removing those certs using GUI does not fix the issue at all. The best way to go is:

-Remove the additional wrong entry from the Certificate DB

-Remove the duplicated entry from the Trusted Certificate List

-Application stop/start ise to restart the services

-Check if the portals are working with no errors or warnings (IF NOT, then you need to do a few more things that I would have to explain in another note.

[jmcgrady1]

What are the CLI commands to restart the web service? Ideally it would only restart the portals (8443) web service and nothing else.

[Sri Harsha Dasari]

We are running 3.1 patch 5 and experienced same issue, portal wouldn't come up after certificate change. Error says there is no certificate binding to the portal. I reloaded the PSN, then everything went back to normal.