I've setup Harbor (a Docker private registry), and am trying to connect to it with Docker.
sudo docker pull registry.mysite.nl/test
But I keep getting:
Using default tag: latest
Error response from daemon: Head https://registry.mysite.nl/v2/test/manifests/latest: Get https://registry.mysite.nl/service/token?scope=repository%3Atest%3Apull&service=harbor-registry: x509: certificate has expired or is not yet valid
If I go to the site using a browser everything works swimmingly, though.. Happens to all clients, on my Mac, on the localhost on that machine etc.
Any idea? -- I regenerated the certificates multiple times etc..
Edit:
The certificate I get from letsencrypt has:
CLIENT_CERT
INTERMEDIDIATE_CERT
ROOT_CERT
all in one file. Checking the cert with OpenSSL gives an error on the validation
➜ certs openssl s_client -CApath /etc/ssl/ -connect registry.mysite.nl:443
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
0 s:/CN=registry.mysite.nl
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
When I REMOVE the ROOT_CERT from this file (on the server), the error goes away:
➜ certs openssl s_client -CApath /etc/ssl/ -connect registry.mysite.nl:443
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = registry.mysite.nl
verify return:1
---
Certificate chain
0 s:/CN=registry.mysite.nl
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X
But Docker (and podman) keep complaining about invalid certificates.
x509: certificate has expired or is not yet valid: current time 2022-02-17T17:19:53Z is after 2016-01-12T16:41:00Z
Related
I' trying to get hostapd working with eap-peap and a Let's encrypt certificate. When connecting with my Android phone though, it does not connect and complains the certificate was expired.
hostapd logs
wlan0: STA <mac> IEEE 802.11: authenticated
wlan0: STA <mac> IEEE 802.11: associated (aid 1)
wlan0: CTRL-EVENT-EAP-STARTED <mac>
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
SSL: SSL3 alert: read (remote end reported an error):fatal:certificate expired
OpenSSL: openssl_handshake - SSL_connect error:0A000415:SSL routines::sslv3 alert certificate expired
wlan0: CTRL-EVENT-EAP-FAILURE <mac>
wlan0: STA <mac> IEEE 802.1X: authentication failed - EAP type: 0 (unknown)
wlan0: STA <mac> IEEE 802.1X: Supplicant used different EAP type: 25 (PEAP)
wlan0: STA <mac> IEEE 802.11: deauthenticated due to local deauth request
Client configuration
EAP Method: PEAP
Identity:
Password:
CA-Certificate: Use System Certificate
Domain:
Phase2 Authentication: MSCHAPV2
Anonymous Identity:
When configuring the CA-Certificate validation mode to "no validation" however, the connection works flawlessly.
Certificate
> openssl x509 -in /etc/hostapd/certs/server.pem -text
[...]
Validity
Not Before: Jan 29 09:40:58 2023 GMT
Not After : Apr 29 09:40:57 2023 GMT
Subject: CN = <domain>
[...]
hostapd.conf
# EAP Settings
eap_server=1
ieee8021x=1
eapol_version=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=TKIP
rsn_pairwise=CCMP
eap_user_file=/etc/hostapd/hostapd.eap_user
ca_cert=/etc/hostapd/certs/ca.pem
server_cert=/etc/hostapd/certs/server.pem
private_key=/etc/hostapd/certs/server.key
hostapd.eap_user
# Wildcard for all other identities
* PEAP,TTLS,TLS
# Phase 2 (tunnelled within EAP-PEAP or EAP-TTLS) users
"testaccount1" MSCHAPV2 "SuperSecretPassword1" [2]
On my Windows machine, these settings work flawlessly, the certificate is presented to me and I can decide to accept it (or not). However, the validation method is very different on Windows.
I'm therefore wondering if any of you have experience with this on Android.
I'm also confused with the lines
wlan0: STA <mac> IEEE 802.1X: authentication failed - EAP type: 0 (unknown)
wlan0: STA <mac> IEEE 802.1X: Supplicant used different EAP type: 25 (PEAP)
This looks to me like I misconfigured somethin in eap_user - but then again it is working as long as certificate validation is not enabled.
For anyone looking for an answer to this:
Above configuration actually works flawlessly with Windows and iOS. Only getting Android to work requires a different configuration in hostapd.conf and on the Android device:
in hostapd.conf:
For ca_cert, download the Root-CA that is used in the certificate chain for signature of the intermediate CA which signed your server.pem. In my case, this was ISRG Root X1. All Let's Encrypt certificates are available on https://letsencrypt.org/de/certificates/
For server_cert, the fullchain.pem file is used, containing the server certificate and the intermediate certificate chain.
on Android:
Download the same Root CA and add it specifically as Wifi Certificate. This certificate needs to be selected when connecting.
It appears as if Android does not use the system certificate store or the system certificate store for wifi certificates does not contain the Let's Encrypt Root CA. Therefore, this CA needs to be added manually rendering the process on android much more complicated on unmanaged devices.
I am running a vagrant box with Centos 7 as its OS. I installed blackfire without error and then tried to profile from the web browser. It started profile, but then just hung and hung and never finished. I then tried it via curl in the command line and got the following error:
$ blackfire curl https://gitlist.demo.blackfire.io/
Profiling: [####------------------------------------] 1/10
Error while running command: exit status 60
Use the option '--ignore-exit-status' to ignore command exit status
* About to connect() to gitlist.demo.blackfire.io port 443 (#0)
* Trying 54.76.137.79...
* Connected to gitlist.demo.blackfire.io (54.76.137.79) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=gitlist.demo.blackfire.io
* start date: Jul 07 14:09:16 2019 GMT
* expire date: Oct 05 14:09:16 2019 GMT
* common name: gitlist.demo.blackfire.io
* issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
* NSS error -8181 (SEC_ERROR_EXPIRED_CERTIFICATE)
* Peer's Certificate has expired.
* Closing connection 0
curl: (60) Peer's Certificate has expired.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a
"bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Can someone explain to me what this error is? I have used Blackfire successfully on other projects (albeit, those were Ubuntu boxes) and have never seen this error. I can't find much on the web about this as well.
cURL is not sending the HTTP request because the "Peer's Certificate has expired".
As suggested, you could have added the "--insecure" option.
But it seems the certificate has been renewed.
On our build servers we use signtool.exe to sign our artifacts.
The same arguments are passed to signtool.exe each time, but it fails or passes sporadically due to our certificate not being used because of a "private key filter".
We have been using this process for a while but we started seeing failures the morning of March 27, 2019.
We start the signtool.exe process with the following arguments:
sign /fd sha256 /f "cert.p12" /p certPass /du hostSiteHere /v /debug /tr timeStampUrl "fileNames"
Specifications
- signtool.exe is from the windows 10 sdk
- build servers are hosted in AWS as windows 2016 server ec2 instances
- jenkins (v2.1.68) runs the builds using the amazon ec2 plugin (v1.42)
The logs, depending on if it passes or fails:
PASS
The following certificates were considered:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
The following additional certificates will be attached:
Issued to: DigiCert SHA2 Assured ID Code Signing CA
Issued by: DigiCert Assured ID Root CA
Expires: Sun Oct 22 12:00:00 2028
SHA1 hash: digiCertSigningSha1Hash
Done Adding Additional Store
FAIL
The following certificates were considered:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 0 certs were left.
No certificates were found that met all the given criteria.
Odd behaviors to note:
the same ec2 instance can work successfully and then fail later
an ec2 instance failing may start working if a user RDPs into the ec2 instance
the same certificate, signtool.exe and arguments are being passed every time
After building my own eventmachine/thin with SSL support on windows (Install OpenSSL with Ruby for eventmachine on Windows 7 x86) I got another problem with SSL certificate: when I use build-in self-signed one thin works fine but it does not respond to any request while using corporate certificate
Here is my path for obtaining the certificate:
I generated private key with puttygen (ssl-private.key)
I generated CSR using following command:
openssl req -out ssl.csr -key ssl-private.key -new
I sent CSR to CA and received P7B file
I converted P7B using following command:
openssl pkcs7 -inform DER -outform PEM -in cert.p7b -print_certs > cert.crt
What could go wrong here?
What have I checked:
openssl rsa -in ssl-private.key -check
says "RSA key ok"
openssl x509 -in cert.crt -text -noout
says
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
***
Signature Algorithm: sha1WithRSAEncryption
Issuer: ***
Validity
Not Before: Feb 16 08:47:25 2004 GMT
Not After : Feb 16 08:55:36 2024 GMT
Subject: ***
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
***
Exponent: 3 (0x3)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
***
1.3.6.1.4.1.311.21.1:
...
Signature Algorithm: sha1WithRSAEncryption
***
while the same check made on self-signed cert, created using
openssl genrsa -des3 -out server.orig.key 2048
openssl rsa -in server.orig.key -out server.key
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
says
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
***
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=PL, ST=-, O=Internet Widgits Pty Ltd, CN=test.org
Validity
Not Before: Jun 24 14:42:07 2015 GMT
Not After : Jun 23 14:42:07 2016 GMT
Subject: C=PL, ST=-, O=Internet Widgits Pty Ltd, CN=test.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
***
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
***
ok some change: I have changed certs order in crt file so that final cert is not last but first and the result is different: chrome drops an error of NET::ERR_CERT_INVALID, IE similar and both does not navigate further
openssl s_client output (looks ok, *** Root CA 1 is trusted in windows):
Loading 'screen' into random state - done
CONNECTED(000001E8)
depth=1 DC = com, DC = ***, CN = *** Enterprise CA 1
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=***/ST=***/O=***/CN=***.com
i:/DC=com/DC=***/CN=*** Enterprise CA 1
1 s:/DC=com/DC=***/CN=*** Enterprise CA 1
i:/DC=com/DC=***/CN=*** Root CA 1
---
Server certificate
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
subject=/C=***/ST=***/O=***/CN=***.com
issuer=/DC=com/DC=***/CN=*** Enterprise CA 1
---
No client certificate CA names sent
---
SSL handshake has read 3404 bytes and written 665 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID: ***
Session-ID-ctx:
Master-Key: ***
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket: ***
Start Time: 1435319943
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=0
I have made a simple https server (lib/emtestssl):
require 'rubygems'
require 'bundler/setup'
Bundler.require
class ServerHandler < EM::Connection
def post_init
puts "post_init"
start_tls :private_key_file => 'private.key', :cert_chain_file => 'comb.crt', :verify_peer => false
end
def receive_data(data)
puts "Received data in server: #{data}"
send_data("HTTP/1.1 200 OK\n\nHello world!")
close_connection_after_writing
end
end
EventMachine.run do
puts 'Starting server...'
EventMachine.start_server('145.245.202.233', 443, ServerHandler)
end
it works fine without tls, with tls browser won't allow to connect :(
as per http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#verify private key and certificate do match
it looks like (patched) eventmachine is completely fine: i have taken key/cert pair from existing server and (after a url mismatch warning from the browser) it works fine
after comparing the certificates it looks like my CA has failed and brought me a cert with wrong properties: working one is described as Server Authentication (1.3.6.1.5.5.7.3.1) while failing one is Client Authentication (1.3.6.1.5.5.7.3.2)
i will issue another csr and charge them for lost day... :/
maybe one important discovery is an order of certificates within cert file: one must go from the final cert to the root being at the end of the chain
I wrote a python app that sends push notification to Apple devices.
Suddenly notifications are no longer received, on all the iOS apps.
It looks like Apple returns an error after sending the notification.
I would like to know if the following response looks normal?, or if there is an issue with the certificates?
$ openssl s_client -connect gateway.push.apple.com:2195 -cert /home/ubuntu/webapps/notification/certificates/relax_app/production/apns-dev-cert.pem -key /home/ubuntu/webapps/notification/certificates/relax_app/production/apns-dev-key-noenc.pem
CONNECTED(00000003)
depth=1 C = US, O = "Entrust, Inc.", OU = www.entrust.net/rpa is incorporated by reference, OU = "(c) 2009 Entrust, Inc.", CN = Entrust Certification Authority - L1C
verify error:num=20:unable to get local issuer certificate
verify return:0
140149704410784:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired:s3_pkt.c:1195:SSL alert number 45
140149704410784:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:591:
---
Certificate chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc./OU=iTMS Engineering/CN=gateway.push.apple.com
i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFEzCCA/ugAwIBAgIETBzSBzANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xMjA1MDMxODIyMjhaFw0xNDA1MzEw
OTI5MDZaMIGHMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAG
A1UEBxMJQ3VwZXJ0aW5vMRMwEQYDVQQKEwpBcHBsZSBJbmMuMRkwFwYDVQQLExBp
VE1TIEVuZ2luZWVyaW5nMR8wHQYDVQQDExZnYXRld2F5LnB1c2guYXBwbGUuY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt4u3gyk9GeQGIH7pmYSA
604LxMLvaUZkgeXOLRzH/48LZgPD5megHhsvjj6du2xzOQKb7iCVYF4HnHf3k00R
3iXtvEmqRU87uw8K2LPu9ZfoNcJpu2e45eF27dXjvjCmvlMDsPxFBer9nAex3P4o
mGCld73SfcZuIB3bQ6BFTIM6je+0nNwP9yuSF4XjOrOx+1+ifgGwyl9T/qa1TYWW
K/LmObAmpbBYwklu33NVOR4BBrZ+GAdj1irdZqh3s3R+b/ANaAAbx2YYrScnIP15
OG7oYNKO3zzIQ0KaBjJjv30j5dXFQaIiphUWhuhQ3rRMmG7xV5UWVqHMriMLD4bS
PQIDAQABo4IBWTCCAVUwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMB
BggrBgEFBQcDAjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmVudHJ1c3Qu
bmV0L2xldmVsMWMuY3JsMGUGCCsGAQUFBwEBBFkwVzAjBggrBgEFBQcwAYYXaHR0
cDovL29jc3AuZW50cnVzdC5uZXQwMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuZW50
cnVzdC5uZXQvbDFjLWNoYWluLmNlcjBABgNVHSAEOTA3MDUGCSqGSIb2fQdLAjAo
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAfBgNVHSME
GDAWgBQe8auJBvhJDwEzd+4Ueu4ZfJMoTTAdBgNVHQ4EFgQULkkf+RyRucrBgaw2
Iu+V+aUctU4wCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAPSQnfPByAF+Y
ML2kwujhbKMZw81oF3HGkdSG756Jt5cqiBJB+KS+4ZThpTgAr9EytfHtl4NPoBwZ
I0a2gLvmO2HNe5OqVSdOqyPCCFN0aBZTYwLVHM3HmoUbPn+Zh19g7Me4AC69IR9i
RoJmzSkagR+Z7z7veiSzfeUHaGa0YUsyc7iMerF1rFfYJvXFVp4D1gA672nTzctZ
0e0yItFXJrN6FL/K+NKCk/O3HCn95oVEPtnEWF2Qm91AZKoCYV1u3VzWtlZsyjQL
wqfQNpr+VUe1SQ1DInr2enCQrCBnH7R3JVscj91cfEiH1SydpRrNFICT40nphEWK
higEADTWUQ==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc./OU=iTMS Engineering/CN=gateway.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
No client certificate CA names sent
---
SSL handshake has read 2670 bytes and written 2047 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: F2FEDB49795DA0B3084B850521A514EB60EE9959C40753AB79B799CA4F6225DAA4FE7084B8CF6D7BF9A4AEB92B9B3A06
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1385498375
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Note
The response returns the following:
verify error:num=20:unable to get local issuer certificate
Does this error prevent sending push notifications? or can it be ignored?
Thanks in advance.
SOLUTION
The issue was related with expired and revoked certificates.
New certificates were generated according to this great tutorial:
http://www.raywenderlich.com/32960/