Errors while provisioning certificate with SAN values

[snowake4me]

First and foremost: Thanks for this outstanding tool, which we have used extensively to really streamline and enhance our interaction with ACM across a large collection of accounts. Great stuff!

I've long since avoided the use of SANs - in part, because it's so easy to crank out whatever vanity FQDN a team may require / desire. However, I find myself with a use case requiring a SAN - and for whatever reason, I can't seem to get the DomainValidation records created. I've experimented a bit with where I place the SubjectAlternativeNames: property, and can get some different results based on that placement - but can't seem to get the validation records to be created.

I'm even starting with the SIMPLE scenario where I'm trying to include a SAN from the same sub-domain / Route53 Hosted Zone. Ultimately, I need to include a SAN from a 'foreign' (non-Route53 hosted) domain - but I'll cross that bridge when I come to it.

I'm using syntax that looks like this, for my custom resource:

 GeneratedCertificate:
    Properties:
      DomainName: !Ref pCertificateSubject
      SubjectAlternativeNames:
        - !Ref pSubjectAlternativeName
      DomainValidationOptions:
        - DomainName: !Ref pCertificateSubject
          HostedZoneId: !Ref pHostedZoneId
      ServiceToken: !GetAtt 'CustomAcmCertificateLambda.Arn'
      Route53RoleArn: !Ref pRoute53AssumedRoleArn
      Tags:
        - Key: Name
          Value: !Ref pCertificateSubject
        - Key: Owner
          Value: !Ref pCFNOwnerTag
        - Key: App
          Value: !Ref pAppName
        - Key: Env
          Value: !Ref pEnv
      ValidationMethod: DNS
    Type: Custom::DNSCertificate

and when it executes, I'm getting a "CREATE_FAILED" with an error:

Received response status [FAILED] from custom resource. Message returned: DomainValidationOptions missing for mysanvalue.example.com (RequestId: 24307790-d42e-4608-94b9-c0d4b1a89631)

(SAN value changed to protect the innocent. Both the Subject, and the SAN, are both within the same Route53 Hosted Zone).

What am I doing wrong? At first I thought perhaps the SAN required it's own DomainValidationOptions - experimented with that, but then looking at the README - that doens't seem to be the case. I'm sure it's something obvious, whatever it is... :)

Thanks again for this super helpful tool!

[snowake4me]

Issue closed: PEBCAK.

I realized the difference between the example in the documentation, and the values I was using (the full FQDN within DomainValidationOptions:).

I was able to figure it out, and resolved by changing my custom resource code to:

  GeneratedCertificate:
    Properties:
      DomainName: !Ref pCertificateSubject
      SubjectAlternativeNames:
        - !Ref pSubjectAlternativeName
      ValidationMethod: DNS
      DomainValidationOptions:
        - DomainName: !Ref pCertificateSubject
          HostedZoneId: !Ref pHostedZoneId
        - DomainName: !Ref  pSubjectAlternativeName
          HostedZoneId: !Ref pHostedZoneId
      ServiceToken: !GetAtt 'CustomAcmCertificateLambda.Arn'
      Route53RoleArn: !Ref pRoute53AssumedRoleArn
      Tags:
        - Key: Name
          Value: !Ref pCertificateSubject
        - Key: Owner
          Value: !Ref pCFNOwnerTag
        - Key: App
          Value: !Ref pAppName
        - Key: Env
          Value: !Ref pEnv
    Type: Custom::DNSCertificate

Problem solved! Now on to bigger and better (e.g. my target state) where one domain validation is automated (within Route53 in a Shared Services account) and the other is not (a sub-domain hosted at the enterprise level on security appliances).

Thanks AGAIN! #NowUsingOneMoreFeature