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:
- Apple devices - Checking for Universal Links configuration
- Android devices - Verifying Digital Asset Links
- 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:
- Verify file permissions (should be readable by web server user)
- Check for correct MIME types (application/json for JSON files)
- 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 Clipsassetlinks.json
- Used by Android for Digital Asset Links (App-to-Website verification)
These requests are coming from:
- Apple devices checking app association
- Android devices verifying app links
- 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:
- Verify directory permissions:
chmod 755 /.well-known
- Check web server configuration allows access
- Ensure files are actually present (empty requests may indicate misconfigured apps)
- 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