// TODO: limit what IP addresses can be used? Only private? Only certain ranges (i.e. only allow the specific ranges by default, configuration for all?)
// TODO: can DNS already be limited to a certain domain? That would probably be nice to have too, but maybe not as part of this PR
// TODO: if it seems not too big of a change, make consts/enums out of the stringly typed identifiers (challenge types, identifier types)
// based on configuration? Public vs. private range? That logic should be configurable somewhere.
// TODO: ensure that DNSNames indeed MUST NEVER have an IP
// TODO: only allow IP based identifier based on configuration?
// TODO: validation of the input (if IP; should be valid IPv4/v6; Incoming request should have Host header set / ALPN IN-ADDR.ARPA)
// TODO: limit the IP address identifier to a single IP address? RFC _can_ be read like that, but there can be multiple identifiers, of course
// Determine if DNS names or IPs should be processed.
// At this time, orders in which DNS names and IPs are mixed are not supported. // TODO: ensure that's OK and/or should we support more, RFC-wise
shouldProcessIPAddresses:=len(csr.DNSNames)==0&&len(orderIPs)!=0// TODO: verify that this logic is OK and sufficient
ifshouldProcessIPAddresses{
// Validate identifier IPs against CSR alternative names (IPs).
// TODO: only allow IP based identifier based on configuration? Some additional configuration and validation on the provisioner for this case.
// Validate identifier names against CSR alternative names.
//
// Note that with certificate templates we are not going to check for the
// absence of other SANs as they will only be set if the templates allows
// them.
iflen(csr.IPAddresses)!=len(orderIPs){
returnsans,NewError(ErrorBadCSRType,"CSR IPs do not match identifiers exactly: "+
returnsans,NewError(ErrorBadCSRType,"number of CSR IPs do not match identifiers exactly: "+
"CSR IPs = %v, Order IPs = %v",csr.IPAddresses,orderIPs)
canonicalized.IPAddresses=uniqueSortedIPs(csr.IPAddresses)// TODO: sorting and setting this value MAY result in different values in CSR (and probably also ending up in cert); is that behavior wanted?