Mac OSX Catalina + tunnelblick SSL/TLS handshake failed - macos
I have installed a brand new Desktop iMac running Catalina version 10.15.4
And since yesterday I have had problems to authenticate on OpenVPN using Tunnelblick. I am currently using Tunnelblick 3.8.2 (build 5480)..
Bellow you can check the error logs from it.
*Tunnelblick: macOS 10.15.4 (19E266); Tunnelblick 3.8.2 (build 5480); Admin user
git commit 6155bb774cf9652ef0231b712d7784ee03d3c85e
Configuration vpngate_vpn244287220.opengw.net_udp_1673
"Sanitized" condensed configuration file for /Library/Application Support/Tunnelblick/Shared/vpngate_vpn244287220.opengw.net_udp_1673.tblk:
dev tun
proto udp
remote vpn244287220.opengw.net 1673
cipher AES-128-CBC
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
client
verb 3
<ca>
[Security-related line(s) omitted]
</ca>
<cert>
[Security-related line(s) omitted]
</cert>
<key>
[Security-related line(s) omitted]
</key>
================================================================================
Files in vpngate_vpn244287220.opengw.net_udp_1673.tblk:
Contents/Resources/config.ovpn
================================================================================
Configuration preferences:
-routeAllTrafficThroughVpn = 1
-openvpnVersion = -
-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0
-loggingLevel = 3
-lastConnectionSucceeded = 0
================================================================================
Wildcard preferences:
-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0
================================================================================
Program preferences:
buildExpirationTimestamp = 1587379876
launchAtNextLogin = 1
tunnelblickVersionHistory = (
"3.8.2 (build 5480)",
"3.8.1 (build 5400)"
)
lastLaunchTime = 606821074.439207
lastLanguageAtLaunchWasRTL = 0
connectionWindowDisplayCriteria = showWhenConnecting
maxLogDisplaySize = 102400
lastConnectedDisplayName = vpngate_118.241.144.186_udp_1195
keyboardShortcutIndex = 1
updateCheckAutomatically = 1
NSWindow Frame ConnectingWindow = 1085 937 389 187 0 0 2560 1417
NSWindow Frame SUUpdateAlert = 970 783 620 392 0 0 2560 1417
detailsWindowFrameVersion = 5400
detailsWindowFrame = {{1267, 756}, {920, 468}}
detailsWindowLeftFrame = {{0, 0}, {167, 350}}
detailsWindowViewIndex = 0
detailsWindowConfigurationsTabIdentifier = log
leftNavSelectedDisplayName = vpngate_vpn244287220.opengw.net_udp_1673
AdvancedWindowTabIdentifier = connectingAndDisconnecting
haveDealtWithOldTunTapPreferences = 1
haveDealtWithOldLoginItem = 1
haveDealtWithAfterDisconnect = 1
SUEnableAutomaticChecks = 1
SUScheduledCheckInterval = 86400
SULastCheckTime = 2020-03-25 09:24:34 +0000
SUHasLaunchedBefore = 1
WebKitDefaultFontSize = 16
WebKitStandardFont = Times
buildExpirationTimestamp = 1587379876
================================================================================
Tunnelblick Log:
2020-03-25 09:26:50.201403 *Tunnelblick: macOS 10.15.4 (19E266); Tunnelblick 3.8.2 (build 5480)
2020-03-25 09:26:50.512597 *Tunnelblick: Attempting connection with vpngate_vpn244287220.opengw.net_udp_1673; Set nameserver = 769; monitoring connection
2020-03-25 09:26:50.513215 *Tunnelblick: openvpnstart start vpngate_vpn244287220.opengw.net_udp_1673.tblk 58118 769 0 3 0 1098544 -ptADGNWradsgnw 2.5_git_32723d2-openssl-1.1.1e
2020-03-25 09:26:50.531516 *Tunnelblick: openvpnstart starting OpenVPN
2020-03-25 09:26:50.794089 OpenVPN 2.5_git_32723d2 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 22 2020
2020-03-25 09:26:50.794152 library versions: OpenSSL 1.1.1e 17 Mar 2020, LZO 2.10
2020-03-25 09:26:50.795069 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:58118
2020-03-25 09:26:50.795116 Need hold release from management interface, waiting...
2020-03-25 09:26:51.136934 *Tunnelblick: openvpnstart log:
OpenVPN started successfully.
Command used to start OpenVPN (one argument per displayed line):
/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5_git_32723d2-openssl-1.1.1e/openvpn
--daemon
--log /Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Svpngate_vpn244287220.opengw.net_udp_1673.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_0_1098544.58118.openvpn.log
--cd /Library/Application Support/Tunnelblick/Shared/vpngate_vpn244287220.opengw.net_udp_1673.tblk/Contents/Resources
--machine-readable-output
--setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5480 3.8.2 (build 5480)"
--verb 3
--config /Library/Application Support/Tunnelblick/Shared/vpngate_vpn244287220.opengw.net_udp_1673.tblk/Contents/Resources/config.ovpn
--setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Shared/vpngate_vpn244287220.opengw.net_udp_1673.tblk/Contents/Resources
--verb 3
--cd /Library/Application Support/Tunnelblick/Shared/vpngate_vpn244287220.opengw.net_udp_1673.tblk/Contents/Resources
--management 127.0.0.1 58118 /Library/Application Support/Tunnelblick/lnkadcnbabkakmcajkcbbhagnilekdiadephbbio.mip
--management-query-passwords
--management-hold
--redirect-gateway def1
--script-security 2
--route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
--down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2020-03-25 09:26:51.145350 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:58118
2020-03-25 09:26:51.214147 MANAGEMENT: CMD 'pid'
2020-03-25 09:26:51.214221 MANAGEMENT: CMD 'auth-retry interact'
2020-03-25 09:26:51.214269 MANAGEMENT: CMD 'state on'
2020-03-25 09:26:51.214311 MANAGEMENT: CMD 'state'
2020-03-25 09:26:51.214356 MANAGEMENT: CMD 'bytecount 1'
2020-03-25 09:26:51.215097 *Tunnelblick: Established communication with OpenVPN
2020-03-25 09:26:51.231465 *Tunnelblick: >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info
2020-03-25 09:26:51.234302 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:51.234590 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2020-03-25 09:26:51.234626 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-25 09:26:51.239204 MANAGEMENT: >STATE:1585128411,RESOLVE,,,,,,
2020-03-25 09:26:51.528796 TCP/UDP: Preserving recently used remote address: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:51.528866 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-25 09:26:51.528884 UDP link local: (not bound)
2020-03-25 09:26:51.528899 UDP link remote: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:51.528956 MANAGEMENT: >STATE:1585128411,WAIT,,,,,,
2020-03-25 09:26:51.834207 MANAGEMENT: >STATE:1585128411,AUTH,,,,,,
2020-03-25 09:26:51.834286 TLS: Initial packet from [AF_INET]121.155.129.51:1673, sid=5882099d 9d031a26
2020-03-25 09:26:52.177465 VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
2020-03-25 09:26:52.177567 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-25 09:26:52.177582 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-25 09:26:52.177593 TLS Error: TLS object -> incoming plaintext read error
2020-03-25 09:26:52.177603 TLS Error: TLS handshake failed
2020-03-25 09:26:52.178015 SIGUSR1[soft,tls-error] received, process restarting
2020-03-25 09:26:52.218256 MANAGEMENT: >STATE:1585128412,RECONNECTING,tls-error,,,,,
2020-03-25 09:26:52.225982 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:52.226119 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2020-03-25 09:26:52.226143 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-25 09:26:52.226301 MANAGEMENT: >STATE:1585128412,RESOLVE,,,,,,
2020-03-25 09:26:52.227535 TCP/UDP: Preserving recently used remote address: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:52.227590 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-25 09:26:52.227607 UDP link local: (not bound)
2020-03-25 09:26:52.227622 UDP link remote: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:52.227643 MANAGEMENT: >STATE:1585128412,WAIT,,,,,,
2020-03-25 09:26:52.227956 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:52.608861 MANAGEMENT: >STATE:1585128412,AUTH,,,,,,
2020-03-25 09:26:52.608945 TLS: Initial packet from [AF_INET]121.155.129.51:1673, sid=24e59327 4db6ce3c
2020-03-25 09:26:53.017553 VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
2020-03-25 09:26:53.017616 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-25 09:26:53.017631 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-25 09:26:53.017642 TLS Error: TLS object -> incoming plaintext read error
2020-03-25 09:26:53.017652 TLS Error: TLS handshake failed
2020-03-25 09:26:53.017813 SIGUSR1[soft,tls-error] received, process restarting
2020-03-25 09:26:53.017836 MANAGEMENT: >STATE:1585128413,RECONNECTING,tls-error,,,,,
2020-03-25 09:26:53.026246 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:53.058693 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2020-03-25 09:26:53.058774 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-25 09:26:53.058959 MANAGEMENT: >STATE:1585128413,RESOLVE,,,,,,
2020-03-25 09:26:53.059957 TCP/UDP: Preserving recently used remote address: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:53.060007 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-25 09:26:53.060023 UDP link local: (not bound)
2020-03-25 09:26:53.060037 UDP link remote: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:53.060058 MANAGEMENT: >STATE:1585128413,WAIT,,,,,,
2020-03-25 09:26:53.060373 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:53.512826 MANAGEMENT: >STATE:1585128413,AUTH,,,,,,
2020-03-25 09:26:53.512940 TLS: Initial packet from [AF_INET]121.155.129.51:1673, sid=e66bd815 2a66696d
2020-03-25 09:26:53.836081 VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
2020-03-25 09:26:53.836141 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-25 09:26:53.836154 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-25 09:26:53.836165 TLS Error: TLS object -> incoming plaintext read error
2020-03-25 09:26:53.836174 TLS Error: TLS handshake failed
2020-03-25 09:26:53.836333 SIGUSR1[soft,tls-error] received, process restarting
2020-03-25 09:26:53.836363 MANAGEMENT: >STATE:1585128413,RECONNECTING,tls-error,,,,,
2020-03-25 09:26:53.838259 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:53.838325 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2020-03-25 09:26:53.838340 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-25 09:26:53.838419 MANAGEMENT: >STATE:1585128413,RESOLVE,,,,,,
2020-03-25 09:26:53.839406 TCP/UDP: Preserving recently used remote address: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:53.839450 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-25 09:26:53.839465 UDP link local: (not bound)
2020-03-25 09:26:53.839480 UDP link remote: [AF_INET]121.155.129.51:1673
2020-03-25 09:26:53.839499 MANAGEMENT: >STATE:1585128413,WAIT,,,,,,
2020-03-25 09:26:53.839702 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:54.140756 MANAGEMENT: >STATE:1585128414,AUTH,,,,,,
2020-03-25 09:26:54.140859 TLS: Initial packet from [AF_INET]121.155.129.51:1673, sid=ce43006a 5a2277a1
2020-03-25 09:26:54.446583 VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
2020-03-25 09:26:54.446650 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-25 09:26:54.446674 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-25 09:26:54.446685 TLS Error: TLS object -> incoming plaintext read error
2020-03-25 09:26:54.446695 TLS Error: TLS handshake failed
2020-03-25 09:26:54.446864 SIGUSR1[soft,tls-error] received, process restarting
2020-03-25 09:26:54.446905 MANAGEMENT: >STATE:1585128414,RECONNECTING,tls-error,,,,,
2020-03-25 09:26:54.457512 MANAGEMENT: CMD 'hold release'
2020-03-25 09:26:54.487380 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
The app seems to go into some sort of loop never authenticating.
Related
What is the default TLS version in Spring boot?
In the documentation the default value for server.ssl.protocol is TLS, but it does not specify which version will be used. I read that TLS 1.3 is available since java 11 but is it used by default in Sprint boot when available? Is there any configuration that can tell me which version is used in my project? Or any documentation depending on the Spring boot version that could tell the TLS version used by the framework?
I am using Spring Boot 2.7.3 and JDK 17 and by default, it supports TLSv1.3 You can check that by running the below command. My application is running locally on port 8080 so I passed 127.0.01:8080 after -connect openssl s_client -connect 127.0.01:8080 Output CONNECTED(00000003) 140704377439424:error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version:/AppleInternal/Library/BuildRoots/810eba08-405a-11ed-86e9-6af958a02716/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/ssl/tls13_lib.c:151: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 294 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Start Time: 1668006818 Timeout : 7200 (sec) Verify return code: 0 (ok) --- You can change the TLS version by this property. server.ssl.enabled-protocols=TLSv1.2 Want to read more about this? refer below links https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto.webserver.configure-ssl https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#application-properties.server.server.ssl.enabled-protocols
Postgres 13 service will not start after installing Postgres 14
I have been using Postgresql 13 on a local server on my Windows 10 computer for over a year successfully now. I decided to upgrade to 14 yesterday. I installed 14 on a different port. I went to go and upgrade as per this command: pg_upgrade -d "c:\Program Files\PostgreSQL\13\data" -D "c:\Program Files\PostgreSQL\14\data" -b "c:\Program Files\PostgreSQL\13\bin" -B "c:\Program Files\PostgreSQL\14\bin" -U Postgres, but it said it cannot connect to the 13 server. I restarted the computer, and still the 13's Service will not start. When I type pg_ctl -D "C:\Program Files\PostgreSQL\13\data" start at the cmd line, the below is what shows in my log: 2022-02-15 08:53:45.908 +04 [92100] LOG: starting PostgreSQL 13.3, compiled by Visual C++ build 1914, 64-bit 2022-02-15 08:53:45.909 +04 [92100] LOG: listening on IPv6 address "::", port 5432 2022-02-15 08:53:45.910 +04 [92100] LOG: listening on IPv4 address "0.0.0.0", port 5432 2022-02-15 08:53:45.954 +04 [92672] LOG: database system was shut down at 2022-02-14 14:08:25 +04 2022-02-15 08:53:45.955 +04 [92672] LOG: invalid record length at 24/80B400C8: wanted 24, got 0 2022-02-15 08:53:45.955 +04 [92672] LOG: invalid primary checkpoint record 2022-02-15 08:53:45.955 +04 [92672] PANIC: could not locate a valid checkpoint record 2022-02-15 08:53:46.057 +04 [92100] LOG: startup process (PID 92672) was terminated by exception 0xC0000409 2022-02-15 08:53:46.057 +04 [92100] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. 2022-02-15 08:53:46.057 +04 [92100] LOG: aborting startup due to startup process failure 2022-02-15 08:53:46.059 +04 [92100] LOG: database system is shut down What should I do to fix this? What I have already done is: PostgreSQL.conf - made sure listen_addresses = '*' was uncommented made sure Modify was valid for all users of the computer on the Postgres Programs folder I checked that the Postgres user had full rights to the folder, but there was no user found in my windows. I added to the pg_hba file: #host all all 0.0.0.0/0 scram-sha-256 oh, and in case it's not apparent, I don't know much about Postgres. I can use it for what I need and that's about it.
As JJanes suggested. I did a backup and then restored in the new server of Postgres 14. It solved the problem. Thank you, JJanes.
How to fix unable to check revocation for the certificate when downloading a remote file in Vagrant
As part of my Vagrantfile I have config.vm.box = "hashicorp/bionic64" config.vm.provision "shell", path: "https://get.docker.com", name: "dockers" I'm behind a corporate proxy. I appended my corporate certificate to C:\HashiCorp\Vagrant\embedded\cacert.pem. Also, I set this environments variable CURL_CA_BUNDLE & SSL_CERT_FILE both to C:\HashiCorp\Vagrant\embedded\cacert.pem which has the certificate. But still vagrant up fails with the following message: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate. INFO interface: Machine: error-exit ["Vagrant::Errors::DownloaderError", "An error occurred while downloading the remote file. The error\nmessage, if any, is reproduced below. Please fix this error and try\nagain.\n\nschannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.\r"] My guess is that Ruby (being used by Vagrant) cannot find the cert or the call to get the revocation list is blocked. Any ideas what is the exact issue here and how to fix it? Update In the debug mode it appears that curl (possibly called from Ruby?) is trying to download the file INFO downloader: Downloader starting download: INFO downloader: -- Source: https://get.docker.com INFO downloader: -- Destination: C:/Users/John/.vagrant.d/tmp/12288a08-a7ba-3d92-96ff-8bf28e739099-remote-script INFO subprocess: Starting process: ["C:\\HashiCorp\\Vagrant\\embedded\\bin/curl.EXE", "-q", "--fail", "--location", "--max-redirs", "10", "--verbose", "--user-agent", "Vagrant/2.2.16 (+https://www.vagrantup.com; ruby2.6.7) ", "--output", "C:/Users/John/.vagrant.d/tmp/12288a08-a7ba-3d92-96ff-8bf28e739099-remote-script", "https://get.docker.com"] DEBUG subprocess: Selecting on IO DEBUG subprocess: stderr: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 99.84.174.91:443... * Connected to get.docker.com (99.84.174.91) port 443 (#0) * schannel: ALPN, offering http/1.1 * schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate. 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * Closing connection 0 * schannel: shutting down SSL/TLS connection with get.docker.com port 443 curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Have a look at this SO answer . As mentioned there, disabling the antivirus software till vagrant init was initialized solved the problem.
LetsEncrypt lego script not working (Bitnami AWS Lightsail)
tl;dr: I used to use certbot to install a new certificate from LetsEncrypt, but that involved manually updating TXT records. So I tried to switch to lego to do it. But when I use lego to install a new certificate, it doesn't actually install a new certificate (old one still shows in browser). Longer version: I'm on an AWS Lightsail instance running Bitnami. I'm a little familiar with Linux, but I wouldn't consider myself "handy" with it. In the past, I used to do the following to renew my certificates: DOMAIN=mydomain.com WILDCARD=*.$DOMAIN sudo certbot -d $DOMAIN -d $WILDCARD --manual --preferred-challenges dns certonly (Install TXT records) sudo /opt/bitnami/ctlscript.sh restart apache However, this is a bit annoying to have to do, and LetsEncrypt helpfully provides the lego library to do this automatically. So based off the documentation I could find, I did the following: $ sudo /opt/bitnami/ctlscript.sh stop Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : httpd stopped /opt/bitnami/php/scripts/ctl.sh : php-fpm stopped /opt/bitnami/mysql/scripts/ctl.sh : mysql stopped $ sudo /opt/bitnami/letsencrypt/lego --tls --email="myemail#domain.com" --domains="mydomain.com" --domains="www.mydomain.com" --path="/opt/bitnami/letsencrypt" run 2020/02/28 16:58:57 [INFO] [mydomain.com, www.mydomain.com] acme: Obtaining bundled SAN certificate 2020/02/28 16:58:57 [INFO] [mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3062019938 2020/02/28 16:58:57 [INFO] [www.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3062019945 2020/02/28 16:58:57 [INFO] [mydomain.com] acme: use tls-alpn-01 solver 2020/02/28 16:58:57 [INFO] [www.mydomain.com] acme: use tls-alpn-01 solver 2020/02/28 16:58:57 [INFO] [mydomain.com] acme: Trying to solve TLS-ALPN-01 2020/02/28 16:58:58 http: TLS handshake error from 74.108.143.17:49475: remote error: tls: illegal parameter 2020/02/28 16:58:58 http: TLS handshake error from 94.6.194.131:59130: remote error: tls: bad certificate 2020/02/28 16:58:58 http: TLS handshake error from 74.108.143.17:49476: remote error: tls: illegal parameter 2020/02/28 16:58:58 http: TLS handshake error from 94.6.194.131:59131: remote error: tls: bad certificate 2020/02/28 16:59:00 http: TLS handshake error from 81.187.9.124:49274: remote error: tls: bad certificate 2020/02/28 16:59:01 http: TLS handshake error from 74.108.143.17:49477: remote error: tls: illegal parameter 2020/02/28 16:59:01 http: TLS handshake error from 94.6.194.131:59136: remote error: tls: bad certificate 2020/02/28 16:59:03 [INFO] [mydomain.com] The server validated our request 2020/02/28 16:59:03 [INFO] [www.mydomain.com] acme: Trying to solve TLS-ALPN-01 2020/02/28 16:59:05 http: TLS handshake error from 94.6.194.131:59137: remote error: tls: bad certificate 2020/02/28 16:59:05 http: TLS handshake error from 74.108.143.17:49478: remote error: tls: illegal parameter 2020/02/28 16:59:06 http: TLS handshake error from 86.163.23.242:53113: remote error: tls: bad certificate 2020/02/28 16:59:08 http: TLS handshake error from 94.6.194.131:59138: remote error: tls: bad certificate 2020/02/28 16:59:08 http: TLS handshake error from 74.108.143.17:49479: remote error: tls: illegal parameter 2020/02/28 16:59:09 [INFO] [www.mydomain.com] The server validated our request 2020/02/28 16:59:09 [INFO] [mydomain.com, www.mydomain.com] acme: Validations succeeded; requesting certificates 2020/02/28 16:59:10 [INFO] [mydomain.com] Server responded with a certificate. $ sudo /opt/bitnami/letsencrypt/lego --tls --email="myemail#domain.com" --domains="unmodchat.com" --domains="www.mydomain.com" --path="/opt/bitnami/letsencrypt" renew --days 90 2020/02/28 16:59:13 [INFO] [mydomain.com] acme: Trying renewal with 2158 hours remaining 2020/02/28 16:59:13 [INFO] [mydomain.com, www.mydomain.com] acme: Obtaining bundled SAN certificate 2020/02/28 16:59:14 [INFO] [mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3062019938 2020/02/28 16:59:14 [INFO] [www.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3062019945 2020/02/28 16:59:14 [INFO] [mydomain.com] acme: authorization already valid; skipping challenge 2020/02/28 16:59:14 [INFO] [www.mydomain.com] acme: authorization already valid; skipping challenge 2020/02/28 16:59:14 [INFO] [mydomain.com, www.mydomain.com] acme: Validations succeeded; requesting certificates 2020/02/28 16:59:14 [INFO] [mydomain.com] Server responded with a certificate. $ sudo /opt/bitnami/ctlscript.sh start /opt/bitnami/mysql/scripts/ctl.sh : mysql started at port 3306 /opt/bitnami/php/scripts/ctl.sh : php-fpm started Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80 After doing that, and restarting my browser, when I look at the certificate details it lists the same expiration date as before (March 20th, less than a month from now). What am I doing wrong? I have a feeling that lego might be installing the certificates to the wrong place, but I'm not quite sure how to find where the "right" place is, nor how to tell lego to put them there.
Solution thanks to Jota Martos from Bitnami. The documentation I found wasn't complete, and skipped step 3 from this documentation: https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#step-3-configure-the-web-server-to-use-the-let-s-encrypt-certificate After completing those mv commands, and using the lego command again, all is working as it should be now. Thanks Jota!
Hyperledger peer node start error
I am getting the following error while running the command to start the peer node.
Error:
grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:5005: getsockopt: connection refused"; Reconnecting to {"127.0.0.1:5005" }
Can anybody help me out ?
This happened to me as well after I just set up a development environment in a vagrant VM, following the instructions from http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build/. The connection to "127.0.0.1:5005" is configured in peer/core.yaml: 167: # orderer to talk to 168: orderer: 127.0.0.1:5005 So, the peer expects an orderer service listening on that port. The oderer service (https://github.com/hyperledger/fabric/blob/master/orderer/README.md) listens on port 5151 by default. This is configured in https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml. Build the orderer with make ordererand start it with orderer. Adjust the port in peer/core.yaml to 5151 (the one that the orderer service listens on), rebuild peer with make peer, start peer node start and you will see that the error message disappeared and peer starts correctly: ... 09:51:50.430 [chaincode] notify -> DEBU 056 notifying Txid:vscc 09:51:50.430 [chaincode] Launch -> DEBU 057 sending init completed 09:51:50.430 [chaincode] Launch -> DEBU 058 LaunchChaincode complete 09:51:50.430 [sysccapi] RegisterSysCC -> INFO 059 system chaincode %s(%s) registered vscc github.com/hyperledger/fabric/core/system_chaincode/vscc 09:51:50.433 [committer] NewDeliverService -> INFO 05a Creating committer for single noops endorser 09:51:50.437 [nodeCmd] serve -> INFO 05b Starting peer with ID=name:"jdoe" , network ID=dev, address=0.0.0.0:7051, rootnodes=, validator=true Nil tx from block Commit success, created a block!