The basic file format

Moonshot ships with a tool, moonshot-webp, to securely and correctly provision credentials onto clients. A basic template is provided at /usr/share/moonshot-ui/default-identity.msht. The format for credential files is simple XML:

<?xml version="1.0" encoding="UTF-8"?>
    <display-name>[i.e. John Smith from Camford University]</display-name>
    <user>[i.e. johnsmith]</user>
    <password>[i.e. correct-horse-battery-staple]</password>
    <services>[optional, see Services]</services>
    <selection-rules>[optional, see Selection Rules]</selection-rules>
      <!-- Either ca-cert and subject, or ca-cert and subject-alt -->
      <ca-cert>[Base64-encoded representation of the APC/IdP's CA root certificate, see Trust Anchors]</ca-cert>
      <subject>[CN value of the APC/IdP's server certificate, see Trust Anchors]</subject>
      <subject-alt>[The DNS/FQDN or IP value in the X509v3 extension of the APC/IdP's server certificate, see Trust Anchors]</subject-alt>
      <!-- Or, alternatively, server-cert only -->
      <server-cert>[SHA-256 hash of the APC/IdP's server certificate, see Trust Anchors]</server-cert>

Trust Anchors

Inclusion of the trust anchor is vital - without it credentials may be exposed to malicious resource providers. This credential format is also used to secure communication between RP's, IdP's and trust routers.

You must use either the Certificate Authority (CA) root certificate or the server certificate as trust anchor.

CA Root Certificate

We recommend that a CA certificate is generated with a long expiry time (in years or decades), and that it is kept safe for subsequent server and user certificate generation cycles.

To use the CA root certificate as a trust anchor, you must populate the one or more of the following tags in the <trust-anchor> section:

To retrieve either the subject or subject-alt information, dump the server certificate's text information. Use OpenSSL as follows:

openssl x509 -noout -text -in server.pem

A sample output of the command would yield:

        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=FR, ST=Radius, L=Somewhere, O=Example Inc./, CN=Example Certificate Authority
            Not Before: Nov 14 16:22:19 2017 GMT
            Not After : Jan 13 16:22:19 2018 GMT
        Subject: C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate/
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: [trimmed]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 CRL Distribution Points: 
                Full Name:
    Signature Algorithm: sha256WithRSAEncryption

The subject value to specify would be:

C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/

The subject-alt value to specify would be the value of the X509v3 Subject Alternative Name value in the text:,

Server Certificate

When your server certificate expires, the credentials must be updated and re-provisioned with the new fingerprint.

To use the server certificate itself as a trust anchor, you must populate the <server-cert> tag in the <trust-anchor> section with the SHA-256 fingerprint of the server certificate.

To obtain this fingerprint, run OpenSSL as follows and strip the colon symbols from the resulting value:

openssl x509 -noout -fingerprint -sha256 -in server.pem

A sample output of the command would yield:

SHA256 Fingerprint=24:98:D7:16:AB:78:23:E4:17:B8:D5:C8:71:3D:F1:6C:FC:E2:15:83:62:91:0D:5A:7D:7D:DE:55:63:E4:CF:2D

The server-cert value to specify would be:



The optional services section is used to determine which services the credential will be automatically used for - each service will be contained in its own tag. For use with a trust router, it is better to use the selection-rules section instead. 


Selection Rules

The optional selection-rules section is used to restrict which services the credential will be automatically used for - for use with a trust router identity, the service type is "trustidentity" for all services. Wildcards are acceptable.