Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 10 days ago.
Improve this question
I removing other versions from cert-manager. After that i install the new version with helm using.
Installation works fine.
but when i use the command:
$ kubectl get orders,challenges,clusterissuers
Error from server: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2
Error from server: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2
Error from server: request to convert CR from an invalid group/version: cert-manager.io/v1alpha2
The CRDs:
Name: orders.acme.cert-manager.io
Namespace:
Labels: app=cert-manager
app.kubernetes.io/instance=cert-manager
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=cert-manager
app.kubernetes.io/version=v1.8.2
helm.sh/chart=cert-manager-v1.8.2
Annotations: cert-manager.io/inject-ca-from-secret: cert-manager/cert-manager-webhook-ca
meta.helm.sh/release-name: cert-manager
meta.helm.sh/release-namespace: cert-manager
API Version: apiextensions.k8s.io/v1
Kind: CustomResourceDefinition
....
Last Transition Time: 2022-06-24T15:25:23Z
Message: no conflicts found
Reason: NoConflicts
Status: True
Type: NamesAccepted
Last Transition Time: 2022-06-24T15:25:23Z
Message: the initial names have been accepted
Reason: InitialNamesAccepted
Status: True
Type: Established
Stored Versions:
v1
i dont found the CR where still using cert-manager.io/v1alpha2 and acme.cert-manager.io/v1alpha2
First of all, suggest to backup all your objects (certs, orders, issuer, clusterissuer, etc. with velero for example) !
Cert-manger documentation suggests using the cert-manager cli as:
cmctl upgrade migrate-api-version
You may need --skip-stored-version-check if you already tried to fix CRD api manually (like described in this issue):
cmctl upgrade migrate-api-version --skip-stored-version-check
Finally, if it's failing with the same message, install the 1.6.3 (if CRD is manually installed, upgrade CRD with 1.6.3) and repeat the command cmctl upgrade migrate-api-version. At last, you can upgrade minor version one by one (1.7, 1.8, etc.) as recommended
Related
I'm trying to use nginx-ingress to create secure connection but i'm getting this error:
I'm using helm chart stable/nginx-ingress version 1.34.2.
I've been searching for this kind of error, I've already config ssl-ciphers and ssl-protocols, add more ciphers suite in order to have more common ciphers between client and server. But i'm still getting this error.
The service i'm trying to build following this flow:
Hope some one can solve this out, or having any suggestion for my problem.
Since Twitter changed their website design, I cannot get a set of tweets from any account by using built-in Zinc classes. It throws an error that says: ConnectionClosed: Connection closed while waiting for data
I am using Pharo 5, and I don't know how to tweak the ZnClient settings in order to keep the connection open or something to the purpose of getting the data.
testTwitter
| client |
self ensureSocketStreamFactory.
self isNativeSSLPluginPresent ifFalse: [ ^ self ].
(client := ZnClient new)
get: 'https://www.twitter.com/pharoproject'.
self assert: client isSuccess.
self assert: (client contents includesSubstring: 'Twitter').
client close
That's the test I have in place, it never passes, and throws the error mentioned above. What's missing here? I did a Ruby script using open-uri, openssl and Nokogiri and it fetched the tweets just fine. Perhaps it's a problem with the SSL connection itself?
The issue here is quite easy to answer, but you won't like it. Your issue is connected to the fact that the Twitter has deprecated support for TLS 1.0, TLS 1.1 on July 15/2019. Your pharo is using the deprecated TLS to connect. That is the reason why you are getting the timeout.
The solution?
You have to compile the new SSL/TLS support yourself which is not an easy task to do. You have to compile in at least TLS 1.2 to be able to connect again. There is lack of Pharo documentation how to compile support for new libraries. My guess is that you are using TLS 1.0 (see a note below) - since Pharo 6.1 (so your Pharo 5.x will have same or older libraries) has libgit2.so compiled against libssl.so.1.0.0 (which has dependency libcurl-gnutls.so.4) - If you update the libraries you can see that those support >= TLS 1.2.
Note:
This is connected to the issue which I have posted some time ago. Nobody upvoted it or answered so it got automatically deleted - you can vote to undelete it: https://stackoverflow.com/questions/51399321/getting-error-when-adding-ossubprocess-to-my-pharo-6-1-on-centos-7-4x (see the bottom of the post for the question). I don't have an answer for that as I have dedicated time to my Smalltalk/X project.
Or just switch to a newer Pharo. Adding your method to ZnHTTPSTest in Pharo 8 just works (tested on Pharo 8 build 686, Ubuntu 18.04.02 LTS with the stable vm in PharoLauncher)
I'm trying to retrieve data from an open data api. I have downloaded the certificate from the site and imported it into STRUST (SSL Client Anonymous).
Then I created a HTTP connection to external server in SM59. In the beginning it worked fine, until last week when the api changed its URL and so its DNS.
Of course it could no longer be reached by the current host. So I did above steps again for the new URL (changed everything accordingly like hostname etc. in SM59), but this time I receive following error:
SSL handshake with 'hostname:port' failed: SSSLERR_CONN_CLOSED (-10)#Remote
Peer has closed the network connection##SapSSLSessionStartNB()==SSSLERR_CONN_CLOSED##
Anyone has an idea on how to solve this?
On another forum someone helped me solve the problem. He pointed me out that the problem lies with SNI see: https://security.stackexchange.com/questions/101965/ssl3-error-when-requesting-connection-using-tls-1-2/102018#102018
https://en.wikipedia.org/wiki/Server_Name_Indication
To solve this problem you need to add following parameter: icm/HTTPS/client_sni_enabled and set it to TRUE on the DEFAULT profile. Afterwards you need to restart the application server in order to activate the effects of the parameter.
Link to the full question on SCN: https://answers.sap.com/questions/473015/sap-ssl-handshake-failed.html
EDIT:
I came across this error again later on, but this time it seemed that the error was caused because we used a certificate with TLS 1.2 which was not supported by our system. You can check this link: https://launchpad.support.sap.com/#/notes/510007 we implemented number 7 to fix this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 5 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
not able to login into server through ssh. so logged in with rsh and when trying to ssh host itself getting error :
no common kex alg: client 'diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1', server 'gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g=='
I found this log in /var/svc/log/network-ssh:default.log
[ May 14 21:23:13 Rereading configuration. ]
[ May 14 21:23:13 Executing refresh method ("/lib/svc/method/sshd restart") ]
[ May 14 21:23:13 Method "refresh" exited with status 0 ]
[ May 14 21:30:25 Stopping because service disabled. ]
[ May 14 21:30:25 Executing stop method (:kill) ]
[ May 14 21:33:08 Enabled. ]
[ May 14 21:33:08 Executing start method ("/lib/svc/method/sshd start") ]
Could not load host key: /.ssh/id_dsa
Could not load host key: /.ssh/identity
Disabling protocol version 1. Could not load host key
[ May 14 21:33:08 Method "start" exited with status 0 ]
thanks in advance.
Looks like the server and client don’t find a common authentication method.
I just got that with a sun cluster here: It only supports diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1, but my Gentoo GNU/Linux ssh server seems to have dropped the group1 algo.
Fixed by changing /etc/ssh/sshd_config on the ssh server to include
KexAlgorithms curve25519-sha256#libssh.org,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
I fear, though, that there was a reason for removing the group1 algorithm from the default. I would not do this on a publicly accessible box.
For reference also see https://security.stackexchange.com/questions/25662/openssh-default-preferred-ciphers-hash-etc-for-ssh2
Turn on verbose ssh which will hopefully show where the issue is.
E.g.
ssh -v host
If that doesn't give enough info, you can try
ssh -vv host
or even
ssh -vvv host
Look for the first error in the output which will hopefully give you clues as to where the issue lies.
Basic put object calls suddenly stopped working (sometimes it succeds). It has been working since long.
Looks like a SSL cert issue.
Stack Trace snippet.
org.jets3t.service.S3ServiceException: S3 PUT connection failed for '/s3_request_message-38afbd8e-7d65-428a-a708-5d34104ded95-4912660956668093023.xml'
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:516)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestPut(RestS3Service.java:800)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.createObjectImpl(RestS3Service.java:1399)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.putObjectImpl(RestS3Service.java:1317)
at org.jets3t.service.S3Service.putObject(S3Service.java:1661)
at org.jets3t.service.S3Service.putObject(S3Service.java:1914)
at com.amazon.lm.utils.aws.S3Box.putFile(S3Box.java:111)
at com.amazon.lm.engine.LMEngine.copyRequestS3(LMEngine.java:350)
at com.amazon.lm.engine.LMEngine.run(LMEngine.java:165)
at com.amazon.lm.engine.discover.DiscoveryEngine.run(DiscoveryEngine.java:156)
at com.amazon.lm.engine.discover.GoogleBaseSearch.run(GoogleBaseSearch.java:25)
at com.amazon.lm.ui.UIDiscoverTask.run(UIDiscoverTask.java:41)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected 'lm-requests-prod.s3.amazonaws.com', received '*.s3.amazonaws.com'
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.verifyHostname(StrictSSLProtocolSocketFactory.java:293)
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:215)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:342)
... 12 more
Looks like Java does not like the wildcard domain presented as '*.s3.amazonaws.com'
per Can Java connect to wildcard ssl... wildcards can be problematic with java.
But as said earlier, we have been using it since long time and suddenly started facing this issue, that too intermittently.
We are using following versions:
jdk: 1.6
jets3: 0.7
openssl:1.0
Has anyone faced this issue? If Yes, Is there any workaround?
This wasn't an issue with the AWSS3JavaClient code, based on the fact that the this problem was happening both with S3 library and with other Java S3 libraries, and the fact that SSL cert verification is done inside the JVM platform library code, not inside our S3 library code.
The problem is that our JVM's keystore didn't have the most recent certificate authorities (CAs) that allow the JVM to form a chain of trust for whatever cert we're getting from the S3 SSL endpoint. This is a fairly common problem with Java and SSL, since the JVM maintains it's own keystore (i.e. it doesn't use certs from the OS).
If you face this problem, try reproducing this issue with other JVMs. Whenever customers have seen this issue in the past, it's been because their local JVM keystore (the keystore ships with the JVM and contains the most recent certs and CAs) has been out of date. Upgrading to the latest JVM version has always fixed this in the past.
Try upgrading your JVM version to recent one, it should help because your keystore must have been expired! :)