feat(certificates): add custom provisioning option
This commit is contained in:
@ -295,4 +295,54 @@ You'll see:
|
||||
- During attacks or high-volume scenarios, logs are flushed more frequently
|
||||
- If 50+ events occur within 1 second, immediate flush is triggered
|
||||
- Prevents memory buildup during flooding attacks
|
||||
- Maintains real-time visibility during incidents
|
||||
- Maintains real-time visibility during incidents
|
||||
|
||||
## Custom Certificate Provision Function
|
||||
|
||||
The `certProvisionFunction` feature has been implemented to allow users to provide their own certificate generation logic.
|
||||
|
||||
### Implementation Details
|
||||
|
||||
1. **Type Definition**: The function must return `Promise<TSmartProxyCertProvisionObject>` where:
|
||||
- `TSmartProxyCertProvisionObject = plugins.tsclass.network.ICert | 'http01'`
|
||||
- Return `'http01'` to fallback to Let's Encrypt
|
||||
- Return a certificate object for custom certificates
|
||||
|
||||
2. **Certificate Manager Changes**:
|
||||
- Added `certProvisionFunction` property to CertificateManager
|
||||
- Modified `provisionAcmeCertificate()` to check custom function first
|
||||
- Custom certificates are stored with source type 'custom'
|
||||
- Expiry date extraction currently defaults to 90 days
|
||||
|
||||
3. **Configuration Options**:
|
||||
- `certProvisionFunction`: The custom provision function
|
||||
- `certProvisionFallbackToAcme`: Whether to fallback to ACME on error (default: true)
|
||||
|
||||
4. **Usage Example**:
|
||||
```typescript
|
||||
new SmartProxy({
|
||||
certProvisionFunction: async (domain: string) => {
|
||||
if (domain === 'internal.example.com') {
|
||||
return {
|
||||
cert: customCert,
|
||||
key: customKey,
|
||||
ca: customCA
|
||||
} as unknown as TSmartProxyCertProvisionObject;
|
||||
}
|
||||
return 'http01'; // Use Let's Encrypt
|
||||
},
|
||||
certProvisionFallbackToAcme: true
|
||||
})
|
||||
```
|
||||
|
||||
5. **Testing Notes**:
|
||||
- Type assertions through `unknown` are needed in tests due to strict interface typing
|
||||
- Mock certificate objects work for testing but need proper type casting
|
||||
- The actual certificate parsing for expiry dates would need a proper X.509 parser
|
||||
|
||||
### Future Improvements
|
||||
|
||||
1. Implement proper certificate expiry date extraction using X.509 parsing
|
||||
2. Add support for returning expiry date with custom certificates
|
||||
3. Consider adding validation for custom certificate format
|
||||
4. Add events/hooks for certificate provisioning lifecycle
|
Reference in New Issue
Block a user