diff --git a/tests/unit-tests/ca.conf.test b/tests/unit-tests/ca.conf.test
new file mode 100644
index 0000000..8459594
--- /dev/null
+++ b/tests/unit-tests/ca.conf.test
@@ -0,0 +1,73 @@
+; The namespace that the NDN Certificate Authority will serve.
+name "/ndn/edu/ucla/cs/zhiyi"
+
+; This section configures parameter(s) of the issued certificates.
+certificate-info
+{
+  ; freshness-period defines the freshness period of newly issued certificates.
+  freshness-period 720
+}
+
+; This ca-anchor section configures the CA certificate.
+;
+; The type defines the type of certificate. Now NDNCERT supports two types:
+;
+;   file; value should be the file name of the certificate file
+;   base64; value should be the Base64 encoded plain text of NDN certificate bytes
+;
+ca-anchor
+{
+  type file
+  value "ca.ndncert.test"
+}
+
+; This challenge-list section defines a list of all available challenge types.
+;
+; It includes one or more challenge. For every challenge, the type should be
+; the unique type identifier of the registered Challenge Module.
+;
+challenge-list
+{
+  challenge
+  {
+    type pin
+  }
+}
+
+;
+validator-conf
+{
+  ; This section defines the trust model for NDNCERT CaModule validator. It consists of rules
+  ; and trust-anchors, which are briefly defined in this file.  For more information refer to
+  ; manpage of ndn-validator.conf:
+  ;
+  ;   man ndn-validator.conf
+  ;
+  ; A trust-anchor is a pre-trusted certificate.  This can be any certificate that is the root
+  ; of certification chain (e.g., NDN testbed root certificate) or an existing default system
+  ; certificate `default.ndncert`.  A rule defines conditions a valid packet MUST have. A
+  ; packet must satisfy one of the rules defined here. A rule can be broken into two parts:
+  ; matching & checking. A packet will be matched against rules from the first to the last
+  ; until a matched rule is encountered. The matched rule will be used to check the packet. If
+  ; a packet does not match any rule, it will be treated as invalid.  The matching part of a
+  ; rule consists of `for` and `filter` sections. They collectively define which packets can be
+  ; checked with this rule. `for` defines packet type (data or interest) and `filter` defines
+  ; conditions on other properties of a packet. Right now, you can only define conditions on
+  ; packet name, and you can only specify ONLY ONE filter for packet name.  The checking part
+  ; of a rule consists of `checker`, which defines the conditions that a VALID packet MUST
+  ; have. See comments in checker section for more details.
+  rule
+  {
+    id "zhiyi interest rule"
+    for interest
+    filter
+    {
+      type name
+      regex ^<ndn><edu><ucla><cs><zhiyi>[<_NEW><_POLL>]<>*$
+    }
+    trust-anchor
+    {
+      type any
+    }
+  }
+}