We Keep Coding

Kerberos uses the IP instead of hostname

I'm writing a Java class to access to Solr (with SolrJ) in a Kerberized Cloudera Virtual Machine with a static IP address (I'm using VMWare) from a windows machine. The problem is that Kerberos returns me the following error: Server not found in Kerberos database (7) - UNKNOWN_SERVER.
This is the complete error:
KRBError:
cTime is Sun Mar 06 03:49:00 CET 1994 762922140000
sTime is Thu Dec 29 16:11:14 CET 2016 1483024274000
suSec is 413432
error code is 7
error Message is Server not found in Kerberos database
cname is cloudera#CLOUDERA
sname is HTTP/192.168.59.200#CLOUDERA
msgType is 30
The problem is that Kerberos uses the IP address of the Virtual Machines (in which Kerberos is installed) instead of the FQDN (= quickstart.cloudera). In fact in Kerberos exists only HTTP/quickstart.cloudera#CLOUDERA principal.
I also tried to rename the service principal from HTTP/quickstart.cloudera#CLOUDERA to HTTP/192.168.59.200#CLOUDERA and it worked, but I broke all cloudera's internal services that use the HTTP original principal.
In the windows hosts file I put: 192.168.59.200 quickstart.cloudera
This is my krb5.conf:
[libdefaults]
default_realm = CLOUDERA
rdns = true
dns_lookup_kdc = true
dns_lookup_realm = true
dns_canonicalize_hostname = true
ignore_acceptor_hostname = true
ticket_lifetime = 86400
renew_lifetime = 604800
forwardable = true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
udp_preference_limit = 1
kdc_timeout = 3000
[realms]
CLOUDERA = {
kdc = quickstart.cloudera
admin_server = quickstart.cloudera
default_domain = quickstart.cloudera
}
[domain_realm]
.cloudera = CLOUDERA
quickstart.cloudera = CLOUDERA
This is my jaas.conf:
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="C:/Binaries/Kerberos/cloudera.keytab"
doNotPrompt=true
useTicketCache=false
storeKey=true
debug=true
principal="cloudera#CLOUDERA";
};
And this is my java test code:
#Test
public void testSecureSolr() {
try {
System.setProperty("sun.security.krb5.debug", "true");
System.setProperty("java.security.krb5.conf","C:\\Binaries\\Kerberos\\krb5.conf");
System.setProperty("java.security.auth.login.config","C:\\Binaries\\Kerberos\\jaas.conf");
LOG.info("-------------------------------------------------");
LOG.info("------------------- TESTS SOLR ------------------");
LOG.info("-------------------------------------------------");
HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
SolrServer solrServer = new HttpSolrServer(CLUSTER_URI_SOLR);
SolrPingResponse pingResponse = solrServer.ping();
LOG.info("Solr Ping Status: "+ pingResponse.getStatus());
LOG.info("Solr Ping Time: "+ pingResponse.getQTime());
} catch (SolrServerException | IOException e) {
e.printStackTrace();
}
}
Any suggestion? Thanks.

SPNEGO / ActiveDirectory / AES256: Checksum failed

I am trying to use SPNEGO / Kerberos5 authentication with Active Directory 2008 and Java. I followed this guide: http://spnego.sourceforge.net/ - "preflight" went well, but later I get the famous exception:
Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:556)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at de.meona.auth.spnego.TestSpnegoAes.main(TestSpnegoAes.java:45)
Caused by: KrbException: Checksum failed
at sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:102)
I had a close look at this post, as the problem seems similar:
checksum failed: Kerberos / Spring / Active Directory (2008)
In order to make the problems reproducible, I wrote a small Java class. I was able to single-step to the line where the exception happens. I think it is because the secret service key used for decryption is different from the secret service key the Active Directory used to encrypt the service ticket. How can this be?
public class TestSpnegoAes {
private static Oid spnegoOid = null;
private static String negotiate = "YIIGowYGKwYBBQUCoIIGlzCCBpOgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBl0EggZZYIIGVQYJKoZIhvcSAQICAQBuggZEMIIGQKADAgEFoQMCAQ6iBwMFACAAAACjggTUYYIE0DCCBMygAwIBBaENGwtNRU9OQS5JTlRSQaIsMCqgAwIBAqEjMCEbBEhUVFAbGWV4ZS13dXR0a2UtMDMubWVvbmEuaW50cmGjggSGMIIEgqADAgESoQMCAQaiggR0BIIEcGT4WR3IzKSxdgGfSZwLUwXKs0AW+0MhOUR5NBQ7oFXdzBxPhEzZ+aNlYAGxiGgCiFFOIDFJuEJhsQ0+Iqd2EKf6VLYQXfRdGD0Zbi4Fzh1bpHzPzo+8UW1XffWg+nAUg7r/QKrkSLrLF0qIfRBseCP2khdKU0xwCRf197aPjJ8y35kGYF/IT3DRTJZbOCCCLPb7szhl3nnUuqfHLcoc//KzPuKKbMMdaw7w3ftZCk9Lx8GIxxxudSLsaa/v8jRtnFxvyLIz4j7CFJus98Qr9IB7oe/c2/L2CbrzdeBwX5MsYCHod0szWl/V7hs96RXtZauhw3dmB+W0PXEZiOBy50cfJLdIJjpPFTf/ET2+22lPbPsEWWxJwZegqMxFEuOTSIjcTigD3Ct5f5HqSuvNKY5J7e5Bk3sWNKdBxW73DRV7ncvX8CTdEVHubjKyc82cdVeOTHO6wGB0V+LQOrwhgmf16Ss5osynEv+rH38e2DH6rYCPKa3PrPnqHJfQ8kutjxjB8D6hQ1CHFXPrlY1j9j0ABJvZcL94N+BpRPLH+Ve78d4WBw3QBw3Aq0Xux/0NEjnznM6D2HEQpEoUZ+reVBp7wwZlXqOc9eVZH6IXys4nIrrQ13BLAi2KqLwZyglanL9vpVfA/zxT8lsZuzkhiowLniPs52kni04zVi5abu7QB0gTAUDAd44a9sXMGTj8UTZIef9TY3XBpKyyQGE5SJUdGSyh1SdhubErA0bHLWNsNhgKnFIA5gFimWA4LsLhEvnIK89vemlHj20VleU0Yre5tsdnMlOYsYOgsrBbL0wMqzIWXHAVjDLtC3+j2cW3PoSmC2FL7vDDPR7Y62x3o1pmyzioyId3LthqZA/G6f24w3xdiZKLCFEnAX3rY0jly7DwbWAByCJufJshGGZWOqOB39HPBxHhgrw/VtDWRGYBApfdSsmumZd3RsLM2xheodDHXjW4twFYM3M0CyvL97FuOuBGIdFceIGgI/kQENbaITLy7B9sxTVy+mT86Fac/a2wUWq+sdryLTdgtgMVZ/xlh79mReXXTdxnvchPtC68Q74KPNYAOitmDdM2tanIwLWcxdHAgMsEef605FDeuH+WjJyT8NomEtyaR9jTRK1/v2agbPZBAIlBkqMlC24/m5A6clxHDPtVKLKVl0/FfBIPdVx57FK6qrJu+QKcEU1sdkbAbanwq3EKCqHKwsyPFPjiP+ujqMF+h2fVD1hbLjaU3bGFodoT+mRQ7j/mwYE3YTBH/9rypzvO5MsVZDqkyqPbJcf/KX5I8Ta68wxaH32jxQBSAlQjVVqKYJNbB7ruJVLg5HZcMnFNz9d+jgYNVFDEl5Q2UgPYdfzspXpf22sX2NDHbhQOvAGXaIoTkhZIkBeCLEeiEE/VqPiqp9CdOtgwGDOzpt1U3Bd+i16MFC3Sd9zufWKQ+52E9r5sRjbypNG71xFykM3IzYMgGIk5/UDmJCHJ4JBGhK4VIoYOW73PU2ZMcu5GcbiSXDGXqTdHpIIBUTCCAU2gAwIBEqKCAUQEggFAJEhKQVHtVkOCR4BD4PkUujH+VvrWYRg2mGc3E4yxgs/asJqLKXHGjr2h08i89SAN63nG8VXuQt9Iwo50eqUOHVKtoRIyASzGQbTU/lIMVjyEg7++hf4Wq/7IJ1fQ4bKk8LSD7/ZawTmPTt0msKCfEDToc85h8fW0YH6SleqBVpbJDS+t2hVVHXhNLfqoC9CVsYsTWUqMLd0sno4b2bzyVxz15PBB007B/hv6JPiy6fH871HHZRImXJ+3pgQtNlVddpDI6dcPDi7+7CFSNnWwMYrixBMcsNj+GahROpiiEm8Mpu7zDNXVJNKmBufBBzE66YjuXYwFKIaVeTxo9/juv5Dy2gRxykoVR/Hq2J2aRuUWk69LbDu30mwQs1gw8n5V4vOujcXHqTJ59B9JixtOGLvNTCg25sVrk/+EmO/nhmc=";
private static GSSManager manager;
// -Dsun.security.krb5.debug=true
// -Djava.security.auth.login.config=login.conf
public static void main(String[] args) throws GSSException, LoginException, PrivilegedActionException {
spnegoOid = new Oid("1.3.6.1.5.5.2");
manager = GSSManager.getInstance();
LoginContext loginContext = new LoginContext("spnego-server");
loginContext.login();
Subject subject = loginContext.getSubject();
GSSCredential serviceCredentials = getServerCredential(subject);
GSSContext context = manager.createContext(serviceCredentials);
byte[] token = Base64.decode(negotiate);
context.acceptSecContext(token, 0, token.length);
}
static GSSCredential getServerCredential(final Subject subject) throws PrivilegedActionException {
final PrivilegedExceptionAction<GSSCredential> action = new PrivilegedExceptionAction<GSSCredential>() {
public GSSCredential run() throws GSSException {
return manager.createCredential(null, GSSCredential.INDEFINITE_LIFETIME, spnegoOid,
GSSCredential.ACCEPT_ONLY);
}
};
return Subject.doAs(subject, action);
}
}
This is my login.conf file:
spnego-server {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
isInitiator=false
keyTab="file:///C:/Temp/krbtest/meona-service.keytab"
principal=meona-service;
};
I you would like to reproduce, I am happy to give the keytab file as well. It was produced on the PDC using "kpass /out keytab /princ meona-service#meona.intra /pass ... /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL".
As the LoginContext login succeeds, I think the key is recovered successfully.
This is the stdout:
Java config name: null
Native config name: C:\Windows\krb5.ini
Found KeyTab C:\Temp\krbtest\meona-service.keytab for meona-service#meona.intra
Found KeyTab C:\Temp\krbtest\meona-service.keytab for meona-service#meona.intra
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> KeyTabInputStream, readName(): MEONA.INTRA
>>> KeyTabInputStream, readName(): meona-service
>>> KeyTab: load() entry length: 75; type: 18
Looking for keys for: meona-service#meona.intra
Added key: 18version: 1
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
If I do not use a keytab, but use pre-authentication, I am able to recover the key, but get the same error later on.
Any ideas?
Here is the krb5.conf I used to generate the SPNEGO negotiate header.
[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_realm = MEONA.INTRA
[realms]
MEONA.INTRA = {
kdc = pdc.meona.intra
default_domain = MEONA.INTRA
}
[domain_realm]
.MEONA.INTRA = MEONA.INTRA
I tried different variants (with/without ".intra", uppercase/lowercase), without success. But after changing the ticket encryption (using the settings of the AD service user) to ARC4/HMAC1, everything works as expected - what is the problem with AES256?

I seen this issue while using Java 17 and Spnego
My Keytab-file contained entries for AES128/256. We have enabled AES-token for the AD account through Support. Then I see a error "checksum failed" (KVN and password are not changed).
Support generates keytab via ktpass. I replace it on the server and after restarting the application the error was resolved.
I re-generated the keytab-file via ktab with the new kvn - keytab also worked.
After enabling AES, you need "refresh" the account in AD for change the KVN parameter. And then the integration will work.

rabbitmq not working with java

I have rabbitmq setup on my machine and it has 3 different queues. One java code is listening to a queue and other queues are sending messages to python codes. Now python codes are working fine but java code seems to have a problem with AMQ. Following error is coming:
Exception in thread "main" com.rabbitmq.client.PossibleAuthenticationFailureException: Possibly caused by authentication failure
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:341)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:590)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:612)
at com.elki.test.Worker.main(Worker.java:73)
Caused by: com.rabbitmq.client.ShutdownSignalException: connection error
at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67)
at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33)
at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:343)
at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:216)
at com.rabbitmq.client.impl.AMQChannel.rpc(AMQChannel.java:202)
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:326)
... 3 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:290)
at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95)
at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:139)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:532)
at java.lang.Thread.run(Thread.java:744)
How come there could be an AuthenticationFailure with java but not with python.
Any help appreciated.
CODE:
public static void main(String[] argv)
throws java.io.IOException,
java.lang.InterruptedException {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("127.0.0.1");
factory.setPort(5672);
com.rabbitmq.client.Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.queueDeclare(TASK_QUEUE_NAME, true, false, false, null);
System.out.println(" [*] Waiting for messages. To exit press CTRL+C");
channel.basicQos(1);
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume(TASK_QUEUE_NAME, false, consumer);
while (true) {
QueueingConsumer.Delivery delivery = consumer.nextDelivery();
String message = new String(delivery.getBody());
System.out.println(" [x] Received '" + message + "'");
"do some work"
System.out.println(" [x] Done" );
int prefetchCount = 1;
channel.basicQos(prefetchCount);
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
}
}

I suspect it's because you haven't set the password nor the username on the ConnectionFactory object, and so it can't authenticate with RabbitMQ. (Perhaps your Python code is passing those in, and so therefore can authenticate.)
Try adding this code before calling factory.newConnection:
factory.setUsername(userName);
factory.setPassword(password);
replacing userName and password as needed for your code.

I had same error. The problem was that the rabbitmq was started with default config on ipv6 protocol. I don't know why, but it does not work on windows linux subsystem.
Force ipv4 helped for me:
cat /etc/rabbitmq/rabbitmq.config
[
{rabbit, [
{tcp_listeners, [{"127.0.0.1", 5672}]}
]}
].
By default rabbitmq uses ipv6 address ::1.
PS^ You need to create config file if there are not exists.

KrbException "Message Stream Modified (41)" when connecting to SMB share using Kerberos

I'm having some issues with Kerberos authentication to perform file management with JCifs (Kerberos extension version 1.3.17)
This is my current configuration of krb5.conf:
[libdefaults]
default_realm = <REALM_NAME_UPPERCASE>
udp_preference_limit = 1
[realms]
<REALM_NAME_UPPERCASE> = {
kdc = <DOMAIN_NAME_UPPERCASE>:88
admin_server = <DOMAIN_NAME_UPPERCASE>
default_domain = <DOMAIN_NAME_UPPERCASE>
}
[domain_realm]
.<domain_name> = <REALM_NAME_UPPERCASE>
<domain_name> = <REALM_NAME_UPPERCASE>
[appdefaults]
kinit = {
renewable = true
forwardable = true
}
And this is code authenticating the user and then trying to find a file on a fileserver in the network:
public static void main (String[] args) throws Exception {
Subject subject = new Subject();
System.setProperty("java.security.krb5.conf", "C:/krb5.conf");
System.setProperty("sun.security.krb5.debug", "true");
Map<String, Object> state = new HashMap<String, Object>();
state.put("javax.security.auth.login.name", "USERNAME");
state.put("javax.security.auth.login.password", "PASSWORD".toCharArray());
Map<String, Object> options = new HashMap<String, Object>();
options.put("debug", "true");
options.put("useFirstPass", "true");
Krb5LoginModule login = new Krb5LoginModule();
login.initialize(subject, null, state, options);
if (login.login()) {
login.commit();
}
String path = "file://HOST/242269/"; // existing file server folder
Kerb5Authenticator kerberosAuthenticator = new Kerb5Authenticator(subject);
SmbFile smbFile = new SmbFile(path, kerberosAuthenticator);
SmbFile[] files = smbFile.listFiles();
for (SmbFile file : files) {
System.out.println(file);
}
}
Now, when I run this code, it says it can authenticate the user with those credentials (when I change the credentials, authentication fails) and it creates a ticket for this user.
When I later on try to retrieve the content of a file directory over CIFS, it gives me the following error:
GSSException: No valid credentials provided (Mechanism level: Message stream modified (41))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at jcifs.smb.SpnegoContext.initSecContext(SpnegoContext.java:80)
at jcifs.smb.Kerb5Authenticator.setup(Kerb5Authenticator.java:196)
at jcifs.smb.Kerb5Authenticator.access$000(Kerb5Authenticator.java:30)
at jcifs.smb.Kerb5Authenticator$1.run(Kerb5Authenticator.java:168)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at jcifs.smb.Kerb5Authenticator.sessionSetup(Kerb5Authenticator.java:166)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:320)
at jcifs.smb.SmbSession.send(SmbSession.java:239)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:925)
at jcifs.smb.SmbFile.connect(SmbFile.java:974)
at jcifs.smb.SmbFile.connect0(SmbFile.java:890)
at jcifs.smb.SmbFile.resolveDfs(SmbFile.java:669)
at jcifs.smb.SmbFile.send(SmbFile.java:783)
at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:2009)
at jcifs.smb.SmbFile.doEnum(SmbFile.java:1758)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1735)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1668)
You can find the complete error log here (some details are obfuscated)
Could someone please get me going in the right direction as to what I'm doing wrong here?

Uppercase of the realm is very important to avoid "Exception: krb_error 41 Message stream modified (41)".
See http://sourceforge.net/p/spnego/discussion/1003769/thread/99b3ff67/

Hate to necrobump but ran into the same problem when launching Spark and Zeppelin inside a Docker container, with the master being a remote Kerberos-enabled YARN cluster. However, in this case, the realm name uppercase/lowercase was not the problem.
After a few hours, I found this thread which suggests removing the following line from the krb5.conf file:
renew_lifetime = 7d
And that solved the issue. Hope this helps someone.

Alternative (and better) answer to removing the renew_lifetime = 7d line in the config, is by allowing the principal to do renewals. In CentOS 7, an example command would be the following:
kadmin -p admin/admin#EXAMPLE.COM
where I assume that admin/admin#EXAMPLE.COM is the Administrator principal, then:
modprinc -maxrenewlife 90day +allow_renewable your_service#EXAMPLE.COM
where I assume the principal for the service that causes the problems is your_service#EXAMPLE.COM; and the 90day renew life is arbitrary.
This solves the issue without removing the renew_lifetime=7d from the krb5.conf file!

Java paypal call never returns result

Java I am using paypal website pro sdk SOAP calls problem is following line of code returns exception after long time
response = (CreateRecurringPaymentsProfileResponseType) caller.call("CreateRecurringPaymentsProfile", request);
Exception is as follows.
java.net.SocketException: Connection reset
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.paypal.sdk.core.soap.SOAPAPICaller.callSOAP(SOAPAPICaller.java:462)
at com.paypal.sdk.core.soap.SOAPAPICaller.call(SOAPAPICaller.java:382)
at com.paypal.sdk.services.CallerServices.call(CallerServices.java:125)
at CreateRecurringPaymentsProfile.callCreateRecurringPaymentsProfileAPI(CreateRecurringPaymentsProfile.java:85)
at CreateRecurringPaymentsProfile.run(CreateRecurringPaymentsProfile.java:50)
at CreateRecurringPaymentsProfile.main(CreateRecurringPaymentsProfile.java:22)
Caused by: java.net.SocketException: Connection reset
Do i need any certificate or some thing else currently i am using proxy in classes folder as follows
# This file contains the properties that needs to be set to make the API call via Proxy.
# To make use of proxy, change PROXY_SET to true, uncomment
# PROXY_HOST and PROXY_PORT properties and set values as illustrated below.
# Note: Just remove the # symbol to uncomment.
# Both PROXY_HOST and PROXY_PORT needs to be set. PROXY_PORT should be a number.
# If any one of these properties are not set or invalid, proxy settings will be ignored
# and this information will be logged.
# PROXY_HOST : IP Address or Host Name of the proxy server
# PROXY_PORT: Port number of the proxy server
PROXY_SET = true
PROXY_HOST=128.1.100.13
# eg: PROXY_HOST = 127.0.0.1
PROXY_PORT=8080
# eg: PROXY_PORT = 808
# The following properties are optional.
# If your proxy need username and password to authenticate,
# just uncomment the following two properties and set values as illustrated below.
# Note: Just remove the # symbol to uncomment.
# PROXY_USERNAME=<your proxy username>
# eg: PROXY_USERNAME =test
# PROXY_PASSWORD=<your proxy password>
# eg: PROXY_PASSWORD =test
My Code as follows
public class CreateRecurringPaymentsProfile {
CallerServices caller;
public static void main(String[] args) {
try {
CreateRecurringPaymentsProfile sample = new CreateRecurringPaymentsProfile();
sample.run();
}
catch (Exception e) {
System.out.println("ERROR: " + e.getMessage());
}
}
public CreateRecurringPaymentsProfile() throws PayPalException {
caller = new CallerServices();
/*
WARNING: Do not embed plaintext credentials in your application code.
Doing so is insecure and against best practices.
Your API credentials must be handled securely. Please consider
encrypting them for use in any production environment, and ensure
that only authorized individuals may view or modify them.
*/
APIProfile profile = ProfileFactory.createSignatureAPIProfile();
profile.setAPIUsername("f_1299578055_biz_api1.gmail.com");
profile.setAPIPassword("152578076");
profile.setSignature("A.SG-Qkp9mcSwx0zh23u89eyCcWGA9MwmCgRlo2193..VNw06q1WbLTx");
profile.setEnvironment("sandbox");
caller.setAPIProfile(profile);
}
public void run() throws PayPalException {
callCreateRecurringPaymentsProfileAPI();
System.out.println("\nDone...");
}
public void callCreateRecurringPaymentsProfileAPI() throws PayPalException {
System.out.println("\n########## Starting CreateRecurringPaymentsProfile ##########\n");
//Replace the token value by actual value returned vy SetCustomerBillingAgreementAPI call
String token="RP-8P463231B6009345R";
String amount ="5.00";
int BF=1;
BillingPeriodType BP = BillingPeriodType.Day;
CreateRecurringPaymentsProfileRequestType request=new CreateRecurringPaymentsProfileRequestType();
CreateRecurringPaymentsProfileResponseType response=new CreateRecurringPaymentsProfileResponseType();
request.setVersion("51.0");
request.setCreateRecurringPaymentsProfileRequestDetails(new CreateRecurringPaymentsProfileRequestDetailsType()) ;
request.getCreateRecurringPaymentsProfileRequestDetails().setToken(token);
request.getCreateRecurringPaymentsProfileRequestDetails().setRecurringPaymentsProfileDetails(new RecurringPaymentsProfileDetailsType());
Calendar start_date = Calendar.getInstance();
start_date.set(2008,5,30);
request.getCreateRecurringPaymentsProfileRequestDetails().getRecurringPaymentsProfileDetails().setBillingStartDate(start_date);
request.getCreateRecurringPaymentsProfileRequestDetails().setScheduleDetails(new ScheduleDetailsType());
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().setPaymentPeriod(new BillingPeriodDetailsType());
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().setDescription("RP-Test- Java SOAP SDK");
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().getPaymentPeriod().setAmount(new BasicAmountType());
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().getPaymentPeriod().getAmount().set_value(amount) ;
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().getPaymentPeriod().getAmount().setCurrencyID(CurrencyCodeType.USD);
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().getPaymentPeriod().setBillingFrequency(BF);
request.getCreateRecurringPaymentsProfileRequestDetails().getScheduleDetails().getPaymentPeriod().setBillingPeriod(BP);
response = (CreateRecurringPaymentsProfileResponseType) caller.call("CreateRecurringPaymentsProfile", request);
if (!response.getAck().equals(AckCodeType.Success) && !response.getAck().equals(AckCodeType.SuccessWithWarning)) {
// do error processing
System.out.println("\n########## CreateRecurringPaymentsProfile call failed ##########\n");
} else {
//success
System.out.println("\n########## CreateRecurringPaymentsProfile call passed ##########\n");
}
}
}
In developer.paypal.com website i have created the following account.
EDIT Deleted for security reasons.

Can you check your java.policy file to check for any restrictions or otherwise, perhaps you need to add SocketPermission there to allow the application to connect

It was a HTTP proxy problem. It was fixed when I removed the HTTP proxy from the network