Video Screencast Help
Backup Exec

Backup Exec and Self Signed Certificates

Created: 17 May 2012 • Updated: 28 May 2014 • 2 comments
BillB of the BE people's picture
0 0 Votes
Login to vote

I've seen some comments out on the Interwebs, particularly from Government users that certain security scanners such as eEye's Retina are flagging self-signed certificates in Backup Exec installations.   Note that while these certificates are used for SSL (actually TLS 1.0) by Backup Exec, these certificates are not exposing a vulnerability.  Here are some reasons why we feel this way. 

First, the flagged certificates are used as signing certificates by the private CAs residing on Backup Exec media server's to sign SSL/TLS certificates for use by the media server and clients so that an NDMP over TLS connection can be established between them.   As Backup Exec's protocol is a closed system, trust is defined by the administrator when they install BE on a computer.  It is assumed that because the administrator knows which computer they are installing the copy of BE they possess, they trust the identity of both the computer and the software installation.   When a certificate is signed by the CA on the BE installation for use by the agent software on the client, this is only done in response to specific user permission at the time the certificate is requested.  As part of the request, the administrator is instructed to verify that the client is in fact the machine they want to talk to (by comparing IP addresses for example).   At this time, the identity of the client machine (and its agent software) is said to be known by the administrator and the agent certificate now signed by the media server is demonstration of this.

Secondly, the certificates expire after one year (the default).  TLS certificates are renewed before the year is up using a new root certificate generated every six months. 

Thirdly, these certificates are *NEVER* installed in a browser's trusted root store.  They are located in a private BE directory that only the software and the administrator have access to.

While it would be nice to use true CA issued intermediate signing certificates (such as from our own Verisign) instead of self signed root certificates, such use would require internet access everytime a certificate is renewed and many installations do not have direct internet access.   We are considering adding an option to allow intermediate signing certificates to replace the self generated root certificates in the future if there is sufficient interest.

 

Comments 2 CommentsJump to latest comment

TTT's picture

What about those of us with our own Certificate Authority (I use Microsoft's Certificate Services, integrated into Active Directory)?  My group policy already handles distribution of my servers' certificates, and I'd prefer to tell Backup Exec to use those instead of its own self-signed certificates.  All my servers have access to my CA servers, it's enabled me to configure IPsec policies using IPsec encryption w/Certificate-based authorization).

You're right, linking to an outside CA would not be practical.  For those without an internal CA, self-signed certs may have to suffice (or possibly set up their own Linux standalone CA?), but I think if a company has already invested in their own internal CA, it should be used whenever possible (remote access cards, storage management UIs, tape libraries, software, Microsoft EFS, etc).

You mentioned adding an option for intermediate certs.  Can the option also be added to tell BE to use my own CA for certificates to eliminate self-signed completely?

0
Login to vote
BillB of the BE people's picture

Actually, that option is probably more feasible than using intermediate signing certificates.  Certainly Microsoft Certificate Services integration (as well as our own internal CA software, natch) would be a good place to start.  We'll definitely look into it.  Thanks!

0
Login to vote