diff --git a/step-ca/configuration.mdx b/step-ca/configuration.mdx
index 4899390c..f1037420 100644
--- a/step-ca/configuration.mdx
+++ b/step-ca/configuration.mdx
@@ -102,7 +102,8 @@ the `--password-file` flag accepts
       "x509": {
         "allow": {
           "dns": ["*.local"]
-        }
+        },
+        "allowWildcardNames": false
       },
       "ssh": {
         "user": {
@@ -252,6 +253,8 @@ the `--password-file` flag accepts
 
   - **template**: default ASN1DN values for new certificates. See [Templates](./templates.mdx).
 
+  - **policy**: authority-wide policy for certificate identifiers. See [Policies](./policies.mdx).
+
   - **disableIssuedAtCheck**: ☠️  disable a check verifying that provisioning tokens must be issued after the CA has booted. This claim is one prevention against token reuse. The default value is false. Do not change this unless you know what you are doing.
 
   - **claims**: default validation for requested attributes in the certificate request. Can be overridden by similar claims objects defined by individual provisioners.
diff --git a/step-ca/policies.mdx b/step-ca/policies.mdx
index 1ca7ef96..78b84069 100644
--- a/step-ca/policies.mdx
+++ b/step-ca/policies.mdx
@@ -83,7 +83,20 @@ A rule for `*.éxàmplê.com` will internally be represented using its internati
 This rule will match `www.éxàmplê.com` as well as its internationalized representation `www.xn–xmpl-0na6cm.com` (and other subdomains).
 
 By default it is not possible to request a certificate with a literal wildcard character in the domain, like `*.example.com`.
-It is possible to configure the policy to allow this.
+It is possible to configure the policy to allow this:
+
+```
+"policy": {
+    "x509": {
+        "allow": {
+            "dns": ["*.example.com"]
+        }
+        "allowWildcardNames": true
+    }
+}
+ 
+```
+
 
 #### Examples
 
@@ -287,7 +300,6 @@ An example is shown below:
             "dns": ["forbidden.local"],
             "ip": ["192.168.0.1"]
         },
-        "allowWildcardNames": false,
     },
     "ssh": {
         "user": {
diff --git a/tutorials/connect-jamf-pro-to-smallstep.mdx b/tutorials/connect-jamf-pro-to-smallstep.mdx
index 2ff25752..579433f1 100644
--- a/tutorials/connect-jamf-pro-to-smallstep.mdx
+++ b/tutorials/connect-jamf-pro-to-smallstep.mdx
@@ -8,7 +8,7 @@ Smallstep can integrate with Jamf Pro to synchronize your device inventory, and
 
 This document also contains [uninstall instructions](#uninstall-smallstep-agent-with-jamf-pro).
 
-# Prerequisites
+# Requirements & Limitations
 
 You will need:
 
@@ -16,6 +16,24 @@ You will need:
 - A [Jamf Pro](https://www.jamf.com/products/jamf-pro/) tenant
 - A [package distribution point](https://learn.jamf.com/en-US/bundle/jamf-pro-install-guide-linux-current/page/About_Distribution_Points.html) configured in Jamf Pro
 
+Client requirements:
+
+- The agent will need to reach the following domains:
+  ```
+  smallstep.com
+  api.smallstep.com
+  gateway.smallstep.com
+  control.infra.smallstep.com
+  *.[team-name].ca.smallstep.com
+  auth.smallstep.com
+  att.smallstep.com
+  ```
+
+Limitations:
+
+- For VPN configurations, only IPSec VPNs are currently supported.
+- “Always-on VPN” or device-wide VPNs are not yet supported in Smallstep-managed configurations.
+
 # Step-by-step instructions
 
 ### Create an API Client in Jamf Pro
diff --git a/tutorials/vpn-setup-guide.mdx b/tutorials/vpn-setup-guide.mdx
index d8ea68a5..d6cbbe27 100644
--- a/tutorials/vpn-setup-guide.mdx
+++ b/tutorials/vpn-setup-guide.mdx
@@ -8,6 +8,8 @@ description: This tutorial describes how to configure Smallstep with VPN servers
 This tutorial describes how to configure your VPN server for certificate-based authentication with Smallstep.
 The Smallstep app can then configure and issue certificates to your clients.
 
+Smallstep's agent software is currently only able to manage IPSec VPN connections.
+
 # Overview of Setup Steps
 
 While the details will differ between VPNs, the process of configuring a VPN server