Skip to main content

Create RA Profile

When the connection with the Authority is successfully established, we can create a service for certificate management. We call it RA Profile.

Create RA Profile using the API​

RA Profile can be created using the RA Profile API. However, before creating it, we need know the required Attributes for the RA Profile. We can get that using the Authority API and the following request:

curl -X GET \
  --cacert [ca-cert] \
  --cert [client-cert] \
  --cert-type [type] \
  -H "Accept: application/json" \
  https://[domain]:[port]/api/v1/authorities/83265efb-35a1-4b48-ae6f-1269b7c41668/raProfiles/attributes
  #https://[domain]:[port]/api/v1/authorities/{uuid}/raProfiles/attributes

This returns the list of applicable attributes for the RA Profile, such as:

[
    {
        "uuid": "87a94421-c5d8-4a23-bb2c-bbee76cb4ea9",
        "name": "template",
        "content": [
            {
                "value": "CodeSigning"
            },
            {
                "value": "EnrollmentAgent"
            },
            ...
            {
                "value": "SubCA"
            },
            {
                "value": "Administrator"
            }
        ],
        "label": "Template",
        "type": "STRING",
        "required": true,
        "readOnly": false,
        "visible": true,
        "list": true,
        "multiSelect": false
    },
    {
        "uuid": "1467ffaa-445c-11ec-81d3-0242ac130003",
        "name": "caAdcs",
        "content": [
            {
                "value": "vmi307469.example.local\\Demo MS Sub CA"
            }
        ],
        "label": "Certification Authority",
        "type": "STRING",
        "required": true,
        "readOnly": false,
        "visible": true,
        "list": true,
        "multiSelect": false
    }
]

Knowing the attributes, we can create the RA Profile using the following request:

curl -X POST \
  --cacert [ca-cert] \
  --cert [client-cert] \
  --cert-type [type] \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data '
  {
    "name": "Web Server RA Profile",
    "authorityInstanceUuid": "83265efb-35a1-4b48-ae6f-1269b7c41668",
    "description": "Quick start",
    "enabled": true,
    "attributes": [
      {
        "name": "template",
        "content": {
          "value": "WebServer"
        }
      },
      {
        "name": "caAdcs",
        "content": {
          "value": "vmi307469.example.local\\Demo MS Sub CA"
        }
      }
    ]
  }' \
  https://[domain]:[port]/api/v1/authorities/83265efb-35a1-4b48-ae6f-1269b7c41668/raProfiles
  #https://[domain]:[port]/api/v1/authorities/{uuid}/raProfiles

When the RA Profile is successfully created, its uuid is sent back:

{
  "uuid": "e045a12a-e114-45ed-90b8-bac7e750e803"
}

Create RA Profile using the Web Interface​

Create RA Profile to manage certificates with the specific certificate template.

  1. Click RA Profiles in the left menu
  2. Click Add new RA Profile (plus symbol )
  3. Fill the columns with the attributes:
    • RA Profile Name: ADCS-WebServer
    • Description: RA profile for webserver certificates
    • Select Authority: MS ADCS authority
    • Template: WebServer
    • Certification Authority: your system certificate authority
  4. Click Create
  5. Click Enable to make RA Profile ready for using, the RA Profile Status would be changed to Enabled.

Configure request attributes​

Request attributes define what the requester fills in on the certificate request form and where each value lands in the issued certificate. This section walks through authoring them; for the why and how they are resolved, see Request Attribute.

  1. Click RA Profiles in the left menu and open the RA Profile created above

  2. Click Edit to open the Edit RA Profile dialog

  3. Switch to the Request Attributes tab

    note

    The Request Attributes tab needs an Authority. When creating a new RA Profile, select an authority first — the dialog tells you: Select an authority to configure request attributes.

  4. In the Authored attributes section, click + Add request attribute and fill in the dialog:

    • Name — internal identifier, unique within this set; not shown to the requester
    • Label — the name shown to the requester on the request form
    • Description — optional help text shown to the requester explaining what to enter
    • Content type — the data type of the value the requester provides
    • Required, List, Multi select — checkboxes controlling how the form field behaves

  5. Pick the Mapping target — where the value lands in the certificate:

    • RDN (subject) — a component of the certificate subject name (e.g. CN, O); select the RDN below. Careful with the codes: SN is Surname (2.5.4.4), not serial number — the subject Serial Number (SERIALNUMBER, 2.5.4.5) is a separate entry, and neither has any relationship to the issued certificate's serial number. A mispick is a valid mapping that no validation will reject.
    • Subject Alternative Name — select the SAN type below: dNSName, rfc822Name (email), iPAddress, uniformResourceIdentifier, otherName, directoryName, or registeredID; for otherName, also fill otherName OID and otherName value encoding
    • Certificate extension — select the Extension below

  6. Choose the Value source:

    • Free input — the requester types any value
    • Static list — the requester picks from a fixed set of values you define below; add them in the Static list values section with Add value (at least one value, values must be unique)

  7. Click Save to add the attribute; repeat for every attribute you need. Use Edit and Remove on the rows to adjust the set later.

  8. Click Update — changes are saved when you click Update

info

The options offered for RDN and Extension come from the OID registry: built-in system entries plus the entries you register under Custom OIDs. The common standards-track extensions are built in; a vendor-specific Certificate Extension OID must be registered there before you can map an attribute to it.

Validation on save

The set is validated when you click Update: every attribute must declare a field mapping, mapped attributes must use string or text content, RDN codes and extension OIDs must be known to the OID registry, and an extension OID may appear only once per attribute. Failures are reported per attribute with the reason.

Configure external CSR validation​

When a client supplies its own CSR, the profile validates it against the resolved request-attribute set in strict or lenient mode — see External CSR validation for what the modes mean and what is checked.

To configure it, open the profile detail and switch to the Validation tab. The Request Validation widget shows the effective mode. Click Edit Request Validation Settings; the switch Use Platform Request Validation Settings controls whether the profile follows the platform default or sets its own mode.