# INFO: Using main config file /etc/dehydrated/config
# !! WARNING !! Extra configuration directory /etc/dehydrated/conf.d exists, but no configuration found in it.
+ Requesting challenge for www.vi-server.org...
+ Responding to challenge for www.vi-server.org...
+ Challenge is valid!
+ Requesting certificate...
+ ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-cert (Status 403)
Details:
{
"type": "urn:acme:error:unauthorized",
"detail": "Error creating new cert :: authorizations for these names not found or expired: vi-server.org",
"status": 403
}
The same script worked some time before...
Originally created by @vi on GitHub (Jul 4, 2017).
`dehydrated --full-chain -s /etc/ssl/vso/key.csr > /etc/ssl/vso/letsencrypt2.crt`
```
# INFO: Using main config file /etc/dehydrated/config
# !! WARNING !! Extra configuration directory /etc/dehydrated/conf.d exists, but no configuration found in it.
+ Requesting challenge for www.vi-server.org...
+ Responding to challenge for www.vi-server.org...
+ Challenge is valid!
+ Requesting certificate...
+ ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-cert (Status 403)
Details:
{
"type": "urn:acme:error:unauthorized",
"detail": "Error creating new cert :: authorizations for these names not found or expired: vi-server.org",
"status": 403
}
```
The same script worked some time before...
For me it seems that you didn't list your CSRs Common Name in the Subject Alternative Name section, which you should do since browsers nowadays don't really care about a certificates Common Name.
Can you please check that and report back?
@lukas2511 commented on GitHub (Jul 4, 2017):
For me it seems that you didn't list your CSRs Common Name in the Subject Alternative Name section, which you should do since browsers nowadays don't really care about a certificates Common Name.
Can you please check that and report back?
don't really care about a certificates Common Name
What is it is a simple certificate that only has a Common Name and no tricky extensions?
@vi commented on GitHub (Jul 4, 2017):
> don't really care about a certificates Common Name
What is it is a simple certificate that only has a Common Name and no tricky extensions?
I think it should also request challenge for vi-server.org bases on CN=. If browsers accept it and Let's Encrypt look at it, why dehydrated shouldn't?
@vi commented on GitHub (Jul 4, 2017):
I think it should also request challenge for `vi-server.org` bases on CN=. If browsers accept it and Let's Encrypt look at it, why dehydrated shouldn't?
Please add vi-server.org as Subject Alternative Name for this to work, this is how it is supposed to work (in dehydrated as well as in the intended usage for this x509v3 extension).
If you want to know more about Common Name being ignored I'd suggest looking for the security changes of Chrome 58 or Firefox 48.
CN will only be parsed by dehydrated when there is no SNI extension in the csr, and is actually only meant to be a fallback, this feature may be removed in the future.
@lukas2511 commented on GitHub (Jul 4, 2017):
Please add vi-server.org as Subject Alternative Name for this to work, this is how it is supposed to work (in dehydrated as well as in the intended usage for this x509v3 extension).
If you want to know more about Common Name being ignored I'd suggest looking for the security changes of Chrome 58 or Firefox 48.
CN will only be parsed by dehydrated when there is no SNI extension in the csr, and is actually only meant to be a fallback, this feature may be removed in the future.
After adding more names to the "Subject Alternative Name" it works.
Maybe dehydrated should warn about poor CSRs?
@vi commented on GitHub (Jul 4, 2017):
After adding more names to the "Subject Alternative Name" it works.
Maybe dehydrated should warn about poor CSRs?
Why should dehydrated warn about poor CSRs? The --sign-csr functionality is clearly marked "(advanced usage)"...
@txr13 commented on GitHub (Jul 4, 2017):
Why should dehydrated warn about poor CSRs? The `--sign-csr` functionality is clearly marked "`(advanced usage)`"...
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @vi on GitHub (Jul 4, 2017).
dehydrated --full-chain -s /etc/ssl/vso/key.csr > /etc/ssl/vso/letsencrypt2.crtThe same script worked some time before...
@lukas2511 commented on GitHub (Jul 4, 2017):
For me it seems that you didn't list your CSRs Common Name in the Subject Alternative Name section, which you should do since browsers nowadays don't really care about a certificates Common Name.
Can you please check that and report back?
@vi commented on GitHub (Jul 4, 2017):
What is it is a simple certificate that only has a Common Name and no tricky extensions?
@vi commented on GitHub (Jul 4, 2017):
Here is the partial text dump of the csr:
@vi commented on GitHub (Jul 4, 2017):
I think it should also request challenge for
vi-server.orgbases on CN=. If browsers accept it and Let's Encrypt look at it, why dehydrated shouldn't?@lukas2511 commented on GitHub (Jul 4, 2017):
Please add vi-server.org as Subject Alternative Name for this to work, this is how it is supposed to work (in dehydrated as well as in the intended usage for this x509v3 extension).
If you want to know more about Common Name being ignored I'd suggest looking for the security changes of Chrome 58 or Firefox 48.
CN will only be parsed by dehydrated when there is no SNI extension in the csr, and is actually only meant to be a fallback, this feature may be removed in the future.
@vi commented on GitHub (Jul 4, 2017):
After adding more names to the "Subject Alternative Name" it works.
Maybe dehydrated should warn about poor CSRs?
@txr13 commented on GitHub (Jul 4, 2017):
Why should dehydrated warn about poor CSRs? The
--sign-csrfunctionality is clearly marked "(advanced usage)"...