It looks like last week (~Dec 2nd 2020), App Center has introduced some changes on their https://api.appcenter.ms endpoint configuration, which result in SSL server certificate validation issue when uploading files:

ERROR: Build step failed with exception
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
Caused: sun.security.validator.ValidatorException: PKIX path building failed
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
	at sun.security.validator.Validator.validate(Validator.java:260)
	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1479)
Caused: javax.net.ssl.SSLHandshakeException

After doing some debugging, it seems to be related to SNI and the fact that when "servername" is not specified explicitly while requesting the api, api.appcenter.ms presents a wrong (self signed Kubernetes Ingress) certificate.

The following steps using openssl could be used to confirm that theory:

• request without specifying the "servername" flag explicitly:

  openssl s_client -showcerts -connect api.appcenter.ms:443

  in the output ("fake" Kubernetes Ingress certificate):

  Server certificate
  subject=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
  issuer=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 1391 bytes and written 421 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : ECDHE-RSA-AES128-GCM-SHA256
      Session-ID: 2D139F6A03B9FAF75A61FD854B03CB24CC646C25DBEC66D3808B2BE8E9512FCC
      Session-ID-ctx:
      Master-Key: A4765DD8043CDE8F44B3633E0DB2B78C32073059E232B7F6116622A9F0A0455E71F0AA4A2AC8507F9A346778F275A2AA
      Key-Arg   : None
      PSK identity: None
      PSK identity hint: None
      SRP username: None
      Start Time: 1607349341
      Timeout   : 300 (sec)
      Verify return code: 21 (unable to verify the first certificate)
  

• request with the "servername" flag explicitly set:

  openssl s_client -showcerts -servername api.appcenter.ms -connect api.appcenter.ms:443

  result (correct certificate):

  Server certificate
  subject=/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/CN=*.appcenter.ms
  issuer=/C=US/O=Microsoft Corporation/CN=Microsoft Azure TLS Issuing CA 06
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 4945 bytes and written 446 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : ECDHE-RSA-AES128-GCM-SHA256
      Session-ID: 91F7E6F2F13056FF416FB09864FB3331CCF63D43CC07E68B2C5682C897398E5F
      Session-ID-ctx:
      Master-Key: 03487026B3BAF22CA42FD4F037ACD7CA4C132A78767097633E7D0D2642D32EEB0C3D7470369AD569D361674A9893BA4F
      Key-Arg   : None
      PSK identity: None
      PSK identity hint: None
      SRP username: None
      Start Time: 1607349413
      Timeout   : 300 (sec)
      Verify return code: 19 (self signed certificate in certificate chain)
  

Unfortunately there is no easy way to workaround it for now (I tried with adding the "fake" certificates to Jenkins cert store, but it looks like every time different "fake" certificate gets returned, so that doesn't work).

I realize that it's not really App Center plugin bug, but more of a configuration oversight from App Center side, so I issued a support ticket for them as well.