Understanding and Implementing the .well-known Directory: Handling Apple App Site Association and Android Asset Links


2 views

The .well-known directory is a standardized location (defined in RFC 8615) where websites can place machine-readable files for various internet protocols and services. This hidden directory serves as a central point for:

  • Mobile app deep linking configurations
  • Security policy declarations
  • Service discovery mechanisms
  • Automated verification processes

The error logs show two primary file requests:

GET /.well-known/apple-app-site-association
GET /.well-known/assetlinks.json

These requests come from:

  1. Apple devices - Checking for Universal Links configuration
  2. Android devices - Verifying Digital Asset Links
  3. Search engine crawlers (like Googlebot) - Validating app-to-web associations

For iOS (apple-app-site-association):

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.example.app",
        "paths": ["/products/*", "/blog/*"]
      }
    ]
  }
}

For Android (assetlinks.json):

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.android",
    "sha256_cert_fingerprints": ["YOUR_APP_CERT_FINGERPRINT"]
  }
}]

To properly serve these files (and avoid 403 errors), add this to your Nginx config:

location ^~ /.well-known/ {
    allow all;
    default_type "application/json";
    try_files $uri =404;
}

While the .well-known directory needs to be publicly accessible, consider:

  • Restricting write access to server administrators only
  • Implementing proper Content-Type headers (especially for JSON files)
  • Regularly auditing the directory contents

If you're still seeing errors after implementation:

  1. Verify file permissions (should be readable by web server user)
  2. Check for correct MIME types (application/json for JSON files)
  3. Ensure no conflicting server rules are blocking access

The .well-known directory is a standardized location (defined in RFC 8615) where web services place special files for discovery, verification, or configuration purposes. This directory typically resides at the root of a domain (e.g., https://example.com/.well-known/).

From your error logs, we see two key file requests:

  • apple-app-site-association - Used by iOS/macOS for Universal Links and App Clips
  • assetlinks.json - Used by Android for Digital Asset Links (App-to-Website verification)

These requests are coming from:

  1. Apple devices checking app association
  2. Android devices verifying app links
  3. Googlebot validating your site's mobile app integrations

Here are some standard files you might encounter:

/.well-known/
├── apple-app-site-association
├── assetlinks.json
├── acme-challenge/  # Let's Encrypt SSL certificates
├── security.txt    # Security contact information
└── change-password # Password change endpoint

For the specific files in your logs, here's how to implement them:

1. apple-app-site-association (AASA)

This JSON file enables Universal Links on iOS. Example:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.example.app",
        "paths": ["/path/*", "/otherpath/*"]
      }
    ]
  }
}

Must be served with:

  • Content-Type: application/json
  • No file extension
  • Accessible via HTTPS

2. assetlinks.json

Android's equivalent for verifying app/website relationships:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.app",
    "sha256_cert_fingerprints": ["YOUR_APP_SIGNING_CERT_HASH"]
  }
}]

For NGINX (which appears in your logs):

location ^~ /.well-known/ {
  allow all;
  try_files $uri =404;
}

# Specific for Let's Encrypt:
location ^~ /.well-known/acme-challenge/ {
  allow all;
  default_type "text/plain";
}

For Apache:

<Directory "/var/www/html/.well-known">
  Require all granted
  AllowOverride None
</Directory>

Proper configuration of .well-known affects:

  • App-to-web linking functionality
  • Search engine indexing of app content
  • Security certificate renewals
  • Security vulnerability reporting

If you're seeing 403 errors like in your logs:

  1. Verify directory permissions: chmod 755 /.well-known
  2. Check web server configuration allows access
  3. Ensure files are actually present (empty requests may indicate misconfigured apps)
  4. Validate JSON syntax if files exist

For testing:

curl -I https://yourdomain.com/.well-known/assetlinks.json
curl -I https://yourdomain.com/.well-known/apple-app-site-association