According to the official ACME.SH documentation link, issuing a certificate is as simple as running the following command:
$ acme.sh --issue --alpn -d example.com
However, I am getting the following error
Error, can not get domain token entry example.com for `tls-alpn-01`
The supported validation types are `http-01` `dns-01` , but you specified: `tls-alpn-01`
I have tried switching from the default ZeroSSL.com to BuyPass.com, but that does not help. It seems that these providers do not allow tls-alpn-01 validation method, but it could be related to something that I am missing.
PS:
To preemptively answer some questions:
I have a valid domain that I replaced with "example.com"
The site is functional on a 443 port, but port 80 is blocked by ISP, hence tls-alpn-01
I am stopping Nginx, and then checking with netstat that port 443 is not bound to a service.
When I run the script with --debug 2 parameter, I get the following value for _authorizations_map variable
_authorizations_map='example.com,{"identifier":{"type":"dns","value":"example.com"},"status":"pending","expires":"2021-08-18T22:53:50Z","challenges":[{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/wYehJ8kQjUDiDadBJ12qKw", "status":"pending","token":"Sfga2N2KwV-2hg3wo1gYAoyFvqV87dRvG2sHw4I6ups"},{"type":"dns-01","url":"https://acme.zerossl.com/v2/DV90/chall/CkrMQdEJthf-TmWvllW-Bg", "status":"pending","token":"_AlgMGzIfSQs7673Su-njnpieba_zLpSYxiUdXDEFnz"}]}'
Same problem, I switched from ZeroSSL to Let's encrypt CA and now it works without problems.
https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052
Edit: oops, sorry.
To tell acme.sh to use Let's encrypt CA
use:
acme.sh --set-default-ca --server letsencrypt
and then try to issue again the certificate in tls-alpn-01 mode
Related
I am trying to obtain an SSL certificate with certbot and the --webroot setting. My current command is:
sudo certbot certonly --webroot -w <path> -d <URL> -d <*.URL>
Every time I run the command I get this error:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
I tried every similar command I found. Please share some help.
I am using ubuntu 18 with the newest certbot version. I also tried certbot-auto
I figured it out: with the http verification (webroot) it is not possible to obtain wildcards (<*.url>).
But it is possible with a DNS challenge (Reference).
Here is an example command for a manual / DNS challenge wildcard certifiat request:
sudo certbot certonly --manual -d *.<domain> -d <domain> --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server acme-v02.api.letsencrypt.org/directory
I want to provide some further reading on this for anyone else struggling - and I'll explain why every solution still didn't work!
Great advice from Letsencrypt ...
https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-an-authenticator-script-must-be-provided-when/153921
https://letsencrypt.org/docs/challenge-types/ - see DNS-01. Basically Certbot has to connect with your DNS provider/api to create temporary records to verify your domain.
BUT ... not all providers allow this ...
https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438
And it turns out mine (Namecheap) doesn't. So in short Wildcards + Certbot + Namecheap are not physically possible!
I'm stuck on how to fix this SSL error --
My SSL certs work fine on Chrome, but in Safari and Firefox I get an error that there is a host name mismatch if I go to www.domain.com instead of just domain.com
I've set up SSL Certificates using Certbot for my domain for both domain.com and www.domain.com
When I check on nginx to make sure that the certificates exist, I run sudo certbot --nginx, then select both of the domains when asked Which names would you like to activate https for?, and for both domain.com and www.domain.com, I get the result "You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry" and asks if I'd like to attempt to reinstall or renew and replace the cert.
I'm not sure what other steps I can take, as last time I installed certbot I simply followed the instructions, did the above for both www and non-www addresses, and it simply worked at both www and non-www!
Does anyone have any suggestions what to do next?
TLDR:
domain.com: works fine in firefox/safari, nginx says cert exists
www.domain.com: host name mismatch in firefox/safari, nginx says cert exists
why?!
After messing with it for a while, and trying #xyz's ssl checker I figured out the following things:
both certs were valid
When I re-installed the certs using certbot, the most recent cert would start working and the previous one would stop working
Turned out that i needed to add the other url as a subdomain to the existing cert and that fixed it!
I used:
sudo certbot -d domain.com -d www.domain.com
and that did the trick
You can check both domains from an external service, e.g. here:
https://www.sslshopper.com/ssl-checker.html
It will tell you if the certificate is correctly installed on both.
You should also open a new tab in Chrome, open developer tools, record network requests, then goto www.domain.com and see what redirects Chrome makes and what URL's it actually makes requests to. Maybe it has some automatic URL changing based on previously successfully resolved URL's.
BrowserStackLocal gives Error: Could not connect to www.browserstack.com!
I am trying to use Charles Proxy with BrowserStackLocal. I want to use Rewrite feature of Charles Proxy. Both Charles Proxy and BrowserStackLocal are running on same Mac Laptop.
I am getting following error. Has anybody run into this problem?
$ ./BrowserStackLocal myKey -proxyHost 192.168.160.113 -proxyPort 8888 -force -forcelocal
BrowserStackLocal v5.5
*** Error: Could not connect to www.browserstack.com!
Configuration Options:
-v
Provides verbose logging
-f
If you want to test local folder rather internal server
-h
Prints this help
-version
Displays the version
-force
Kill other running Browserstack Local
-only
Restricts Local Testing access to specified local servers and/or folders
-forcelocal
Route all traffic via local machine
-onlyAutomate
Disable Live Testing and Screenshots, just test Automate
-proxyHost HOST
Hostname/IP of proxy, remaining proxy options are ignored if this option is absent
-proxyPort PORT
Port for the proxy, defaults to 3128 when -proxyHost is used
-proxyUser USERNAME
Username for connecting to proxy (Basic Auth Only)
-proxyPass PASSWORD
Password for USERNAME, will be ignored if USERNAME is empty or not specified
-localIdentifier SOME_STRING
If doing simultaneous multiple local testing connections, set this uniquely for different processes
To test an internal server, run:
./BrowserStackLocal <KEY>
Example:
./BrowserStackLocal DsVSdoJPBi2z44sbGFx1
To test HTML files, run:
./BrowserStackLocal -f <KEY> <full path to local folder>
Example:
./BrowserStackLocal -f DsVSdoJPBi2z44sbGFx1 /Applications/MAMP/htdocs/example/
View more configuration options at http://www.browserstack.com/local-testing
Charles Proxy generates its own certificates which is signed by 'Charles Root Certificate'. It seems Charles Proxy is modifying the certificate used by BrowserStackLocal due to which the request to BrowserStack fails and you receive "Could not connect to www.browserstack.com!". More information on SSL-Certificates and Charles is available here.
Can you disable this setting in Charles? This will allow BrowserStackLocal use its original certificate and connect to BrowserStack.
I disabled the SSL proxying in Charles Proxy and turned SOCKS . That solved the problem.
I need to modify the docker daemon'a arguments in OSX.
I got an error when pull a private repository without certificate.
2014/11/11 13:40:02 Error: Invalid registry endpoint
https://registry.af-sys.com/v1/: Get
https://registry.af-sys.com/v1/_ping: dial tcp 54.229.102.95:443: i/o
timeout. If this private registry supports only HTTP or HTTPS with an
unknown CA certificate, please add --insecure-registry
registry.af-sys.com to the daemon's arguments. In the case of HTTPS,
if you have access to the registry's CA certificate, no need for the
flag; simply place the CA certificate at
/etc/docker/certs.d/registry.af-sys.com/ca.crt
According to this message I should modify the daemon arguments. How can I do that?
Following Bryan's note, I added the following to the boot2docker profile:
boot2docker ssh -t sudo vi /var/lib/boot2docker/profile
# Insecure Registry
EXTRA_ARGS="--insecure-registry registry.af-sys.com"
boot2docker restart
If you're running Docker for Mac, you can set up some arguments in the UI Preferences:
For example:
add Insecure registries
add Registry mirrors
change the HTTP proxy settings
I have an access to a preconfigured Windows XP 32-bit workstation.
It's under firewall and to get outside it uses http proxy server.
To get proxy settings I need host, port, username and password.
http: // username : password # server : port
I'm able to find the proxy url and port (from PAC - automatic config file),
but I don't know how to get username/password. Is there a way to read it somehow? At least username? I might get the admin rights.
Do you know any tool that can help?
I only found these MS docs about some methods to get proxy config connection, but I don't know how to determinate what's the provided credentials:
WinHttpGetIEProxyConfigForCurrentUser function
WINHTTP_CURRENT_USER_IE_PROXY_CONFIG structure
WinHttpGetProxyForUrl function
I've also found this lib, but it's rather for parsing PAC:
http://code.google.com/p/pacparser/
In windows you cannot get password.
To get connect throw a proxy you have to use SSPI, check libcurl, you can get a connected socket throw proxy, build it with enable-sspi and openssl.
Iterating on Fernando Sanchez's answer and Robert's comment, you need to authenticate via SSPI. In my case I've connected using NTLM using this link
With curl using ntlm :
curl.exe --proxy <proxy_name>:<proxy_port> --proxy-ntlm -U : https://www.google.com
Also to partially answer your question the -U : means from curl man page :
If you use a Windows SSPI-enabled curl binary and do either Negotiate
or NTLM authentication then you can tell curl to select the user name
and password from your environment by specifying a single colon with
this option: "-U :".
You can get the proxy name and port from the windows registry (regedit). Quote from Robert's comment:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings]
It can be present either in a manual way using REG_SZ ProxyServer or using an autoconfiguration script using REG_SZ AutoConfigURL = https://<configuration_url>
If the curl command above fails with Failure when receiving data from the peer maybe you have a curl release without NTLM, SSPI or OpenSSL. Try with the latest curl release