VMware Cloud Community
cmpyx2
Enthusiast
Enthusiast
Jump to solution

SRM and vReplication Help Needed

Hello all.  We are new here and desperately need help with SRM and vReplication.  We had a case open with VMware, but apparently we are an important enough customer as we have been down for over 3 weeks with limited (and very limited) contact with VMware.  We are running vSphere 5.0.1 with self signed certificates and are trying to install both SRM and vReplication.  After completely re-installing vCenter Server at both the protected and recovery sites, we have installed SRM at both locations.  Currently, we are trying to install and configure VRMS.  Even though we deploy VRMS and are able to login into the server, the summary tab never displays the server name and the VRMS will not accept the self signed certificates generated by vCenter and SRM.  Can anyone (not related to VMware) help us.

0 Kudos
1 Solution

Accepted Solutions
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

The message at the attached screenshot -  "Local and remote servers are using different certificate trust methods." is generated by the SRM servers because of different configuration at the two sites. I guess that SRM can be reconfigured to use only thumbprint matching, but I haven't done that before.

If the VRM servers were configured differently, when the message would be "Incompatible certificate trust method used on server 'server:port'. Both VRM Servers must use the same certificate trust method.".

Regards,

Martin

View solution in original post

0 Kudos
20 Replies
vmroyale
Immortal
Immortal
Jump to solution

What build of SRM are you using?

Brian Atkinson | vExpert | VMTN Moderator | Author of "VCP5-DCV VMware Certified Professional-Data Center Virtualization on vSphere 5.5 Study Guide: VCP-550" | @vmroyale | http://vmroyale.com
0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

srm 5.0.1.2645

everything with vCenter and SRM installed without issue, including the self signed certs (and yes, they are sha1).  But, VRMS even though deployed shows disconnected and the when trying to configure, give an error pertaining to the vCenter self signed certificate, thus the service will not start.

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

Perhaps the validation error cause could be seen /opt/vmware/var/log/lighttpd/error.log from inside the VRMS appliance (through there are a lot of other debug messages related to the VAMI UI).


Regards,

Martin

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Hi Martin, let me did this up and will get back with you on any errors found.  Thanks for letting me know where the logs are stored.

Yeah Martin, there are lot of errors pertaining to validation error.  Then I see where we VRMS to create a new self signed certificate.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

It seems that the configuration is not being saved (probably because the service will not start (guessing at this one)), but when I try to configure the VRMS again I receive this error.....

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Going to give this another shot from  the beginning.  Will delete the SRM and VRM databases after removing the VRMS and removing SRM.  Do you think I need to go as far as removing vCenter Server and re-installing again?

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

From the screenshot it looks like the checkbox "Accept only SSL certificates signed by a trusted Certificate Authority" is on - this requires the CA certificate(s) (of local VC, local SRM and the remote VRMS) to be imported in /opt/vmware/hms/security/hms-truststore.jks, also the address at "vCenter Server Address:" field needs to match either the common name or one of the subject alternative names of the local VC certificate.

If the checkbox "Accept only SSL certificates signed by a trusted Certificate Authority" is switched off - the "Accept" button will allow you to continue and assume that you trust the VC certificate by acknowledging its thumbprint value.

In 5.0, both VRMS servers need to be configured with the same setting for "Accept only SSL certificates signed by a trusted Certificate Authority", for 5.1 this is not required.

I'm not quite sure about the SRM 5.0 documentation, but the 5.1 documentation might help you - http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.replication_admin.doc/GUID-FAE28EC2-9136-....

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

It looks like some validation issue with the VC certificate.

Removing of the VRMS database won't help. Perhaps neither VC re-installation.

There is a Managed IP Address runtime setting of VC. The "vCenter Server Address:" in VRMS VAMI Configuration page should be populated with this value by default. That might matter, but only if IP address is filled in "vCenter Server Address:" - there would need to be a subject alternative name in the VC certificate for that IP address (it should be there for the default VC self-signed certificates).

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Hey guys,  Just completed going through everything once again and read your posts.  I do not believe the checkbox is on but I will have to run through the configuration process again.  I do though have 1 other question.  Where is the certificate for the VRMS server stored and can this be exported and imported into the local VC trusted root on each side?

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

The VRMS certificate is in /opt/vmware/hms/security/hms-keystore.jks. You can export it in DER format using the following command:

keytool -exportcert -file /tmp/hms.crt -keystore /opt/vmware/hms/security/hms-keystore.jks -alias jetty

You don't need a password for the export of the certificate (hit Enter when keytool asks for a password during the export).

You might want to import CA certificate for the VRMS certificate (the VRMS certificate itself, if self-signed) in the machine at which the SRM server and the machine(s) at which the SRM C# client UI plugin is installed. The default VRMS certificate, generated from the VAMI UI, does not have subject alternative name pointing to the appliance IP address or FQDN. Also the common name of the Subject field is also neither the IP address, nor FQDN. If you want to have full validation of certificates (not only by thumbprint value), you would probably want to generate the certificates yourself and use a common CA, not self-signed certificates.

Regards,

Martin

0 Kudos
Biliana
VMware Employee
VMware Employee
Jump to solution

Could you please specify the SR number that you have opened? Thanks.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

I have just spent the better part of the weekend completely re-installing everything.  I have uninstalled SRM and vCenter at both locations, deleting the SRM and VRM databases.  After reinstalling vCenter, I do notice one particularity that seems strange.  When I install SRM at the recovery site, it installs without any issue, but at the protected site, it prompts for the server thumbprint even though at both sites, only FQDNs have been used (no IP).  I believe this is the first issue to overcome.  I really do not want to reinstall everything again, especially vCenter because it causes all kinds of error with HA trying to move VMs around when reconnecting the servers.

Biliana, it is irrelavant at this point but the case was 13270208601.  From your concern, it sounds as though you are from VMware, which I have given up on for the experts here in the community and will attempt to resolve myself.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Hi Martin,

Thanks for the information.  Right now I am uninstalling SRM again, and deleting any certificates in the trusted root in regards to vCenter or SRM, and will try installing the SRM again using server thumbprints on both sides.  Hopefully at this point I will be able to pair sites and try to tackle VRMS.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Martin,

Before I go any further, this is the latest update.  After uninstalling SRM at both sites and recreating both databases for SRM and VRMS, I installed SRM at the protected site and was prompted to accept the server thumbprint.  Again, when I installed SRM at the recovery site, this did not occur.  I know this is a major issue since each side is using a different type of authentication.  I am alright with using the server thumbprint, so what would you suggest I have to do to get the recovery site to start prompting for the thumbprint when installing SRM.  We have always used self-signed certificates throughout all VMware installations.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Martin,

Just a question awaiting you expert comment.  Trying to resolve this issue, I have been uninstalling SRM and vCenter; and removing the SRM and VRS databases.  Is it possible/recommended to remove the vCenter database?  Can this be rebuilt from the infomation on the ESXi servers?  Coorect me if I am wrong, but the protected site, no matter how many times vCenter is installed and self signed certificates are made, always prompts for the server thumprint which the recovery site never does.  Is something in regards to the certificate creation stored in the vCenter database?  Is this something that can be modified or the database recreated?  Please advise.  Note that the vCenter server in the protected site is the composer for our View environment as well.

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

I don't believe vCenter Server database has anything to do with the prompts for the certificate thumbprints.

If vCenter database is removed and vCenter Server re-installed, all history for tasks and events will be lost, all VM and datastore folders hierarchy will be lost, OVF environment settings for all VMs, etc. Hosts will need to be re-added.

If the C# VI Client or SRM UI plugin for the C# client prompt for certificate thumbprint - it means that the certificate of a server (vCenter, SRM or VRMS) the client is trying to connect to can not be automatically validated through a CA certificate found in the trust store of the Windows machine on which the client is running. This is not necessarily an issue, but you need to acknowledge the thumbprint values every time you use the client or to import the CA certificate to the client's machine trust store.

Regards,

Martin

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Well Martin,

Thanks for the information.  I will not touch the VC database, and just try another installation of vCenter server (as I have done twice before) to see if there is anything wrong while creating the self signed certificate.  It seems odd that after installing vCenter server at both the protected and recovery sites, and exporting the certificates to the opposite sites installing in that vCenter server trusted root, that the recovery site seems to have no issues with the certificate, but the protected site prompts for the thumbprint.  Will give this another go and let you know.

0 Kudos
cmpyx2
Enthusiast
Enthusiast
Jump to solution

Martin,

I re-did our entire VMware environment with the exception of uninstalling the composer in the protected site (don't want to chance breaking View), otherwise all products were uninstalled and reinstalled, creating self signed certificates using only FQDN.  Have all products reinstalled.  Made sure to copy the rui.crt from the other site and installed in trusted root (did this for both protected and recovery site).  Installed SRM and everything looks good until I try to pair the sites, then I get the attached error about using different certificate methods.  When I installed vCenter server, both side prompted for the thumbprint which was accepted.

Ideas???????

0 Kudos
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

The message at the attached screenshot -  "Local and remote servers are using different certificate trust methods." is generated by the SRM servers because of different configuration at the two sites. I guess that SRM can be reconfigured to use only thumbprint matching, but I haven't done that before.

If the VRM servers were configured differently, when the message would be "Incompatible certificate trust method used on server 'server:port'. Both VRM Servers must use the same certificate trust method.".

Regards,

Martin

0 Kudos