Hello, We have 2 ASA 5520s in Active/Standby on 9.x IOS We have many users that use Windows 7/8 tablets and the Cisco Anyconnect SSL VPN client. They connect to hostname 'vpn.company.co.uk' (our ASA) and when they connect the VPN connection is 'Trusted' as our SSL certificate on the ASAs (Active/Standby) has vpn.company.co.uk in it. We have now changed our company name and I have been asked 2 things. 1.) To get another certificate generated with help from Cisco (webex?) that includes 'vpn.company.co.uk' and the new company name 'vpn.newcompany.com' (FDNS entries are already working, and can be pinged from the internet, both FQDNs go to our ASAs public IP). Having both FQDNs we hope it will not interfere with our current users experience and can connect to either vpn.company.co.uk or vpn.newcompany.com as 'Trusted' with no additional configuration needed to the clients. What type of cert do I need to use (confused totally) 2.) Once the new certificate is working and users are still using vpn.company.co.uk (old name), we would like to replace this with vpn.newcompany.com, how can we seamlessly do this? Will the user connect and download te new xml file? Please provide a solution. I am trying to plan this to happen over the new few weeks, so it is not urgent, but need to make a start on what is involved.
An ASA can only have a single certificate associated with the outside interface for remote access VPN. Unless you can you can get your CA to issue a multi-domain certificate, you have to choose one or the other.
As far as changing over, every time you connect to an ASA via AnyConnect the logon process checks for updates to the profile and downloads it if a new version is available.
In my understanding, whilst having the company's name "vpn.company.co.uk", you generated a certificate request a obtained an SSL certificate from a known CA.
Now, the name of the company will change (or has).
Previously the CN in the certificate was "vpn.company.co.uk", so users connecting to "vpn.company.co.uk" did not see any certificates errors.
To avoid certificate errors after changing the DNS, you should request a new SSL certificate but this time include the new name of the company in the CN field. So, the new certificate will include the correct DNS and all should work fine.
To have your users connect to the new domain, I would recommend the following:
1- Modify the XML profile and add a second server to the "server's list". This new entry will be "vpn.newcompany.com". So your users, firstly connect to the existing domain and download the new profile which now includes the two servers in the drop down menu.
2- Once the transition is done, you educate your users about the new SSL server and eventually edit the XML profile to remove the old connection entry.
Let me know if this is clear.
Thanks, the main goal then is to be able to have a cert that has the new and old FQDN, so when I generate the new cert it should let me use 2?
You may consider the option to coordinate and install the new certificate at the time that the ISP updates the DNS record.
That may save you time and extra efforts.
I see. The 2 FQDNs new and old are already pingable, so if I try and connect with the new FQDN I get a cert error (red warning sign), but I can get the Anyconnect client to ignore which isn't ideal.
This is what Cisco said though:
— If you need multi-domain SSL, we will need to use SAN attribute to add the second fqdn. Unortunately the ASA does not support the inclusion of SAN attribute in the CSR (tracked by bug CSCso70867 ASA doesn't support SAN attributes for the enrollment request). When generating CSR from ASA, only one fqdn can in included.The workaround for this is to use OpenSSL to generate CSR and keys. Once the certificate is received from CA, it should be combined with the key in OpenSSL to create pkcs12 file. After the file is created, it should be imported into ASA. If its ok to use only the new fqdn, then we can generate the CSR from the ASA itself.
Wondered what your thought.
Yes - either the Subject Alternative Name (SAN) or multi-domain certificate. In both cases, it's still only a single certificate representing both your old and new company names on the interface.
Depending on the number and composition of your remote access user population I'd choose between the more-complex-for-IT fancy certificate option vs. just cutting everyone over to the new company name and using a simple root-CA-issued certificate.
Yeahp, that answer you got from us is true.
However, I did not recommend it because it is more expensive and eventually you won't need the second FQDN.
In case I am wrong and you will need both domains then get a SAN.
Not sure if you still have this problem but we have a similar issue. As you know the ASA cannot generate a CSR with SAN attributes. The solution for us was to create a the CSR using OpenSSL and then get it signed and imported on to the ASA.