- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Expired certificate sdadmind service
A vulnerability Scan of our Authentication Manager appliance is reporting an expired SSL certificate that is part of a chain bound to the sdadmind service on TCP port 5550. The finding gave me some detail on the certificate saying the subject is CN=Security Dynamics Technologies Inc, and the Primary CA Root 1 expired in 2017. I cannot find a reference to this cert anywhere in the certificates section of the Operations Console. I opened a ticket with support on this but never got anywhere. They gave me some links to examine the certificate stores through SSH, but I could not find the certificate in question. They ultimately advised me to update to the latest patch, which I did, but that did not resolve the issue.
Can anyone tell me what the sdadmind service is and if there would be an SSL cert bound to it? I need to identify this cert so that I can remove it or replace it with something valid. I have two replica instances setup, and scans of all three appliances are reporting the same thing.
- Tags:
- AM
- Auth Manager
- Authentication Manager
- Community Thread
- Discussion
- Forum Thread
- RSA Authentication Manager
- RSA SecurID
- RSA SecurID Access
- sdadmind
- SecurID
- ssl certificate
- Vulnerability Warning
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Back in 1997 Security Dynamics, the company that eventually bought RSA and re-named itself, generated an MD5 signed Certificate named sdti.cer. It was Issued to and by itself, therefore it was a Root CA signing Certificate. This sdti.cer.file was part of every license for ACE/ Authentication Manager, and was used to sign the server.cer file unique to your licensed deployment. That sdti.cer. file expired in November of 2017. Your server.cer file would expire 20 years after your license file was generated, therefore the earliest adopters of Authentication Manager 8.0 might have an expiration date of 2031.
TCP port 5550 is the auto-registration service port for Authentication Agents for Windows, and auto-registering Windows agents would have been installed with a copy of your server.cer file, which could be downloaded from the Security Console - Access - Authentication Agents.
RSA has documentation / engineering responses that TLS/SSL is only used for obscuring and is not the encryption method used on TCP port 5550. The only way to do that is to download an upgraded license file that has a SHA signed sdti.cer, and deploy a new primary, which could be a rather challenging proposal depending on how many agents you have.
If you open a support case, you can ask the TSE for more details, including the internal KB 35744 | What is the sdti.cer file, and how does it affect an RSA Authentication Manager server deployment?
As well as Engineering responses concerning the use of self-signed certificates and various encryption methods used on our legacy agents, some of which is under NDA.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Back in 1997 Security Dynamics, the company that eventually bought RSA and re-named itself, generated an MD5 signed Certificate named sdti.cer. It was Issued to and by itself, therefore it was a Root CA signing Certificate. This sdti.cer.file was part of every license for ACE/ Authentication Manager, and was used to sign the server.cer file unique to your licensed deployment. That sdti.cer. file expired in November of 2017. Your server.cer file would expire 20 years after your license file was generated, therefore the earliest adopters of Authentication Manager 8.0 might have an expiration date of 2031.
TCP port 5550 is the auto-registration service port for Authentication Agents for Windows, and auto-registering Windows agents would have been installed with a copy of your server.cer file, which could be downloaded from the Security Console - Access - Authentication Agents.
RSA has documentation / engineering responses that TLS/SSL is only used for obscuring and is not the encryption method used on TCP port 5550. The only way to do that is to download an upgraded license file that has a SHA signed sdti.cer, and deploy a new primary, which could be a rather challenging proposal depending on how many agents you have.
If you open a support case, you can ask the TSE for more details, including the internal KB 35744 | What is the sdti.cer file, and how does it affect an RSA Authentication Manager server deployment?
As well as Engineering responses concerning the use of self-signed certificates and various encryption methods used on our legacy agents, some of which is under NDA.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info. I did open a support case, and they gave me exactly none of this information. So I don't think I'll go down that road again. But with this I should be able to convince the security team to write this off as a false positive. Thanks again
