none
Encrypted replication configuration RRS feed

  • 问题

  • Hello,

    I am attempting to configure encrypted replication in a fairly large (10 hosts per site) HyperV environment.  I'm using the following article as a guide:

    https://www.vkernel.ro/blog/configuring-hyper-v-replica-using-certificate-based-authentication-https#anchor009
    https://www.vkernel.ro/blog/set-up-automatic-certificate-enrollment-autoenroll

    From what I am understanding I will require a certificate on each host.  I will also need to add the broker's certificate to the trusted certificate store on each of the hosts that the broker will reside on. Due to the requirement of a certificate on each host it makes a lot more sense to use auto-enrollment to ensure we don't have to manually renew 20+ certificates on the regular basis.

    I'm having a couple of challenges, for one our hosts are running W2K16 HyperV Core, so I cannot use the certificates MMC as described in the article.  Running the MMC remotely does not appear to give me the same options as described in the article.  Can this (or should this) be done in PowerShell instead?  What would the syntax of the certificate request be?

    Are there any other (hopefully better) articles that can help me do this other than the one I found above?

    Thanks.


    2019年9月9日 15:01

答案

  • Don't use MMC or PowerShell to request a certificate AND set up auto-enrollment. The latter completely negates the need for the former. I would always choose auto-enrollment when available because it requires substantially less overall effort.

    I don't see anything overtly bad about the auto-enroll article that you found. I could link my own if you think that a different explanation method would help, but it would only be different, not necessarily better. You need to set up a group policy that instructs the Hyper-V hosts to try to auto-enroll and you need to configure the default "Computer" certificate template, or a derivative, to allow systems to auto-enroll. Once you have done both of those things, the Hyper-V hosts will get a new "Computer" certificate at their next policy refresh (which you can force with "gpupdate /force"). If you haven't found an article that describes one or both of those tasks to your liking, I can link mine.

    ETA: you can also distribute the broker's certificate via Group Policy. Look in Computer Configuration\Windows Settings\Security Settings\Public Key Policies.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.


    2019年9月9日 15:51

全部回复

  • Don't use MMC or PowerShell to request a certificate AND set up auto-enrollment. The latter completely negates the need for the former. I would always choose auto-enrollment when available because it requires substantially less overall effort.

    I don't see anything overtly bad about the auto-enroll article that you found. I could link my own if you think that a different explanation method would help, but it would only be different, not necessarily better. You need to set up a group policy that instructs the Hyper-V hosts to try to auto-enroll and you need to configure the default "Computer" certificate template, or a derivative, to allow systems to auto-enroll. Once you have done both of those things, the Hyper-V hosts will get a new "Computer" certificate at their next policy refresh (which you can force with "gpupdate /force"). If you haven't found an article that describes one or both of those tasks to your liking, I can link mine.

    ETA: you can also distribute the broker's certificate via Group Policy. Look in Computer Configuration\Windows Settings\Security Settings\Public Key Policies.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.


    2019年9月9日 15:51
  • Thanks Eric, that definitely points me in the right direction.  Can the broker certificate request also be automated?  I'm unsure to how (or if) that can be done since the broker is a service, there would be no computer account to apply the GPO to.

    Any thoughts?

    2019年9月10日 14:56
  • Hmm that's an interesting question. The broker certificate is still a computer certificate, so a computer can request it, so auto-enroll is an option. If you're in HA mode then you also need the FQDN of the broker's CNO, but I don't think that's a show-stopper. The bigger trick would be coordinating an auto-enroll process with the certificate selection in replica. Since it's an uncommon occurrence, I would probably not seek to automate it unless you have so many that the manual process consumes an appreciable amount of time. If you did automate, I would elect to do the entire thing in script so that it all happens in a single process. In that light, I still find certreq and certutil easier to use than the various PowerShell overlays that exist today.

    I have it on my schedule to take up the entire certificate process for replica at some point in the next year, but I have not yet done the proper research to give my best answer.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    2019年9月10日 15:33
  • Thanks for all your help up until now Eric.  With your assistance I have gotten the auto enrollment piece working and each HyperV host node now has its own certificate supplied through auto-enrollment.  I'm still unclear on the broker certificate piece (I'm fairly new to working with certificates). 

    "If you're in HA mode then you also need the FQDN of the broker's CNO."

    We are in HA mode. 

    What are my next steps?  I believe (please correct me if I'm wrong) that I need to make a certificate request from a windows machine on behalf of the broker (since the broker is a role and not an actual computer).

    Within the certificate request I need to specify the CNO (Cluster name object?)

    I then need to apply the certificate to the broker (Where/how do I do this?)

    Once the certificate has bee put on the broker, I think need to export the certificate to all the HyperV hosts which could potentially host the service (I'm also unsure how/where this needs to be exported from and imported to).

    Any assistance you could provide would be greatly appreciated!

    2019年9月13日 18:00
  • First thing, you need a certificate template that allows you to override the common name and add subject alternative names. For use as a Replica Broker, the template must provide the "Server Authentication" and "Client Authentication" Enhanced Key Usages. I have an article on configuring templates: https://www.altaro.com/hyper-v/windows-ssl-certificate-templates/. I believe that the default Computer template allows both Server Auth and Client Auth, so copy that. Then update the copy so that it allows a requestor to use the "Supply in the request" option for subject names. Set security on the template so that your user account can enroll. It's all in the article. I don't recall now if I mentioned it, but you might also want to extend the enrollment period from the default length. Make doubly certain that the template marks the private key as exportable.

    Next, you need to submit a CSR with the appropriate names. I have an article on that as well: https://www.altaro.com/hyper-v/request-ssl-windows-certificate-server/. I would use the MMC method in this case, but you could also use certreq. You want to create the request with a Common Name of the FQDN of the broker's CNO. You want to include Subject Alternate Names (DNS) of the FQDN of the broker's CNO and the FQDN of all nodes. I also personally include all IPs in the Subject Alternate Names list.

    Once you have the certificate, you then need to export it AND the private key. Then, import the cert/key pair into the "Personal" branch of the computer certificate store on all nodes. After that, just tell replica to use the certificate.

    Make sure to zealously guard the cert/private key files. If anyone else gets the private key, your replica environment is compromised.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    2019年9月16日 14:12
  • Hi Eric,

    Thanks again for all your help so far!  Making progress, I have .pfx certificate.  Just so I'm clear, I do NOT have to install the certificate directly on the broker itself?  Instead I import the certificate to each host in the cluster and then select that certificate on the broker?

    One other question, all of our host nodes are core, is there an easy way to import the certificate on each node?  MMC does not work for this remotely.

    2019年9月16日 16:15
  • Just so I'm clear, I do NOT have to install the certificate directly on the broker itself? Instead I import the certificate to each host in the cluster and then select that certificate on the broker?

    Add the certificate/key to each node's local computer store. I don't believe there is a way to assign a certificate to the broker role (by certificate import, I mean). If there is, then do that. Either way, it needs to be on each node separately. I don't think you do anything for the role other than tell it what cert to use, and it only allows selection from certificates in the local computer store.

    One other question, all of our host nodes are core, is there an easy way to import the certificate on each node?  MMC does not work for this remotely.

    Why does MMC not work remotely? Does your domain policy block it or something? Windows Admin Center is the next easiest alternative: https://aka.ms/WindowsAdminCenter.

    If you can't use MMC or WAC, then certutil -importcert (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#-importcert) is your tool. I haven't done it in a while, but there should be plenty of examples on the Internet.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.


    2019年9月16日 16:30
  • This is the error I'm referring to attempting to import the certificate remotely using MMC:

    I am using Powershell to import the certificate using these commands:

    $mypass= get-credential 

    $mypwd = Get-Credential -UserName 'Enter password below' -Message 'Enter password below'
    Import-PfxCertificate -FilePath C:\broker.pfx -CertStoreLocation Cert:\LocalMachine\Personal -Password $mypwd.Password

    This appears to work in the sense that the certificate appears in the certificate store, however I'm still getting the same error when attempting to use the certificate on the broker:


    Here is something I'm really struggling with:


    "Each node on the cluster must have a certificate with the CN equal to (or DNS name containing) the FQDN of the individual node..."

    Does this mean that the name of each hyperV host node must be contained as Subject Alternative Names on the certificate?  If so, this sounds like a management nightmare.  Would I need to re-issue a certificate every time I add/remove a host node to the cluster??



    2019年9月16日 18:11
  • Weird on the MMC part... I was certain that I had imported a PFX remotely before... but my memory lies sometimes. Anyway, you got past that.

    Yes, the certificate must use a Common Name of the broker CNO's FQDN and have SANs with the broker CNO's FQDN and every node's FQDN. Yes, if you add a node you would need to issue a certificate that contains its name. How often do you plan to add nodes? You could skip to the end and issue the initial certificate with enough FQDNs to cover all likely names. None of these systems care if all the SANs exist or not.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    2019年9月16日 18:21
  • Okay, that clarifies it quite a bit.  We have two physical sites with a cluster in each site and a broker in each cluster.  Can we use the same certificate for each broker and ALL hosts as long as it has the FQDN of the broker's CNO as a SAN?  Or do we need a different certificate for each physical site's cluster?
    2019年9月16日 18:56
  • I would guess that the technology would allow you to use the same certificate on both ends. But, the primary purpose of certificates is to verify identity. The identities that you're trying to protect are the brokers. If two brokers use the same certificate, that defeats most of the purpose of using certificates in the first place. Use one per site.

    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    2019年9月16日 19:07
  • Still not working.  I an unclear what CNO refers to.  Right now we are using the FQDN of the broker on the Cert, because I thought CNO was the container name object --> But should it actually be the name of the cluster?  Cluster Name Object?  Also, are CNO and CN the same thing?
    2019年9月17日 12:27
  • CNO = cluster name object. It is a computer account in Active Directory that belongs to a cluster access point.

    When you created the HA Replica role, you should have assigned a name and an IP. The name shown in the wizard is the short name.

    This is not the same CNO as the cluster's primary access point. You can put both into your certificate if you want, but it MUST have the FQDN of the broker CNO.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    2019年9月17日 15:50
  • Replication is working, did a start from scratch and discovered our certificate had Server Authentication only, once we added Client authentication it finally started working.  That's for all your invaluable assistance!
    2019年9月17日 16:14