java.net.SocketException:A system call received a parameter that is not valid.

error

java.net.SocketException:A system call received a parameter that is not valid.

dddzr 2025. 12. 18. 06:50

📌 IBM JDK (WebSphere) 환경에서 HTTPS API 호출 시 A system call received a parameter that is not valid 에러 트러블슈팅

🚀 결론 요약

1. 에러는 HTTP(API호출) 파라미터가 유효하지 않은게 아니라 socket / protocol 상태이다.

2. 서버(WebSphere)에서 외부 HTTPS로 나가는 Outbound TLS 트래픽이 차단됨.

→ 이는 네트워크/보안 장비 정책 영역으로 보안팀에Outbound 허용(SSL Inspection 예외) 요청이 필요함.

3. 2번이 아니라면 API서버 측 legacy SSL 사용을 의심할 수 있다.

🔍 1. 문제 증상

Spring 기반 배치에서 외부 HTTPS API 호출 시

로컬 PC(Windows)에서는 정상 동작
개발 서버(WebSphere)에서 아래 오류 발생

ERROR=org.springframework.web.client.ResourceAccessException:
I/O error on POST request for "https://api.example.com/api/apiurl":
A system call received a parameter that is not valid.;
nested exception is java.net.SocketException:
A system call received a parameter that is not valid.

HTTPS POST 시 SocketException 이고, 에러 포인트는 Spring RestTemplate → SSL 소켓 생성 단계.

ResourceAccessException

└─ java.net.SocketException

A system call received a parameter that is not valid

이 에러는 애플리케이션 로직 문제가 아니라 “JVM + OS + SSL 설정” 문제일 확률이 높다.

🌟에러 전파 흐름

[클라이언트 서버]
 TLS ClientHello 전송 시도
        ↓
[네트워크/보안 계층]
 아웃바운드 TLS 차단 또는 RST
        ↓
[IBM JDK JSSE2]
 정상적인 TLS 응답 수신 불가
        ↓
[OS Socket Layer]
 소켓 write 실패 → invalid parameter
        ↓
[java.net.SocketException]
        ↓
[Spring ResourceAccessException]

👉 여기서 말하는 parameter는
HTTP(API호출) 파라미터가 아니라 socket / protocol 상태

✅ 실행 방법

*로컬 실행 (직접 터미널에서)

java \
  -Dapp.home=./config \
  -cp "bin;lib/*" \
  com.example.batch.MainApplication \
  {MODE} {TARGET}

*서버 실행 (sh 일부)

/path/to/java/bin/java \
  -Dfile.encoding=UTF-8 \
  -classpath ${CLASSPATH} ${JAVA_OPTIONS} \
  -Xms256M -Xmx1024M \
  com.example.batch.MainApplication \
  ${MODE} ${TARGET} \
  > ${LOG_HOME}/batch_${TARGET}_${MODE}_$(date +%Y%m%d).log 2>&1 &

📌 2. TLS(SSL)통신 확인

📌 2-1. 서버(WebSphere) - openssl

*오래된 서버라 curl 설치 안 되어있음 (아마 CentOS).

AIX / IBM 서버에는 openssl이 있는 경우가 많음.

✅ openssl

openssl s_client는 TLS(SSL) 클라이언트 테스트 도구로, HTTPS 통신에서 HTTP를 제외한 TLS 계층까지만 검증한다.

👉즉, Java(Spring RestTemplate)의 HTTPS 통신 중 TLS Handshake 단계까지를 거의 그대로 재현.

✔️ openssl 수행하는 단계

TCP 443 연결
TLS ClientHello 전송
서버와 Cipher Suite 협상
서버 인증서 수신
인증서 체인 검증
TLS Handshake 완료 여부 확인
* HTTP 요청(GET/POST)은 전송하지 않음 → TLS 계층만 단독으로 검증

실행

$ openssl s_client -connect api.example.com:443 -tls1_2

결과

**만약 결과가 아래와 다르다면 다른 원인이다. 3~5 참고!!

CONNECTED(00000003)
write:errno=73
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1765933594
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

해석

✔️ CONNECTED

TCP 443 연결 성공 → 방화벽 / L4 문제 x

❌ write:errno=73

클라이언트가 ClientHello를 보내려는 순간 OS 레벨에서 write 실패
AIX 기준 errno 73 = Protocol error / invalid argument 계열
👉 즉, TLS 데이터 자체가 상대에게 전달되기 전에 커널/보안 계층에서 차단

❌ no peer certificate

서버가 아무것도 응답 안 함
인증서 문제 ❌ (아직 거기까지도 못 감)

❌ read/write 0 bytes

TLS Handshake 시작조차 안 됨
상대 서버가 인증서를 보낸 게 아니라 우리 쪽에서 패킷을 못 내보냄

❓ API 제공자 문제일 경우

ClientHello는 나감
ServerHello / 인증서 응답 있음
handshake_failure / bad_certificate 같은 에러 발생

🚀 결론

서버 → 외부 방향(outbound) TLS 차단

서버에서 외부 HTTPS(API) 호출 시, TCP 443 연결은 정상이나 TLS ClientHello 단계에서

openssl s_client -tls1_2 기준 write errno=73 발생하며 서버로부터 SSL 응답 수신되지 않음.

애플리케이션(Java/Spring)과 무관하게 OS/보안/네트워크 레벨에서 아웃바운드 TLS가 차단되는 것으로 보이며, 해당 서버 → api.example.com:443 경로에 대해 SSL Inspection 또는 보안 정책 확인이 필요하다.

📌 2-2. 로컬 - curl (안 해도 됨. 서버와 비교)

✅ curl

curl은 HTTPS 클라이언트, HTTPS 통신(TLS 협상) 확인

👉 Java(Spring RestTemplate)가 하는 동작을 거의 그대로 재현

✔️ curl 수행하는 단계

TCP 443 연결
TLS ClientHello
서버와 Cipher 협상
서버 인증서 수신
인증서 검증
HTTP 요청 전송

시도

 curl -vk https://api.example.com/…

-v : TLS Handshake 상세 출력
-k : 인증서 검증 무시 (CA 문제 배제용)

결과

* Host api.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 211.46.114.70
*   Trying 111.11.111.11:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
* Connected to api.example.com (111.11.111.11) port 443
* using HTTP/1.x
> GET /... HTTP/1.1
> Host: api.example.com
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Wed, 17 Dec 2025 01:23:13 GMT
< Content-Type: text/html
< Content-Length: 146
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host api.example.com left intact

해석

✔️ DNS / 네트워크

* Connected to api.example.com (111.11.111.11) port 443

DNS 정상, TCP 443 정상 → 네트워크 문제 없음

✔️ TLS(SSL) 계층 (가장 중요)

* schannel: disabled automatic use of client certificate

* ALPN: curl offers http/1.1

* ALPN: server did not agree on a protocol. Uses default.

schannel → Windows TLS 스택
TLS handshake 정상 완료, 서버가 정상적으로 응답 👉 TLS 협상 성공
*ALPN은 선택 사항 → 문제 아님

✔️ HTTP 계층

> GET /... HTTP/1.1

< HTTP/1.1 404 Not Found

< Server: nginx

❓TLS 실패였다면 → 여기까지 못 옴
❓인증서 문제였다면 → handshake 단계에서 컷
❓API 서버 문제였다면 → 5xx 가능성
*404는 URL 경로 문제일 뿐, 통신 성공의 증거임
nginx가 요청을 “받아서 처리”함

📌 3. (참고) API 서버 측 응답 받았다면 가능한 시나리오 정리

⚠️ 본 항목은 실제 발생한 상황이 아닌, 가상 시나리오 정리임. 나는 2번에서 해결되었지만 다른 경우에도 같은 에러가 날 수 있어서 정리함.

✅ 3-1. TLS 단계에서 다른 응답을 받았을 경우 가능한 해석

openssl s_client -connect api.example.com:443 -tls1_2

🔹 legacy SSL 응답 예시 → API서버 또는 앞단 SSL 장비의 legacy SSL 구현 가능성

CONNECTED(00000003)

SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

SSL alert number 40

🔹 SSLv3 only / downgrade 예시 → API SSLv3 기반 응답

CONNECTED(00000003)

wrong version number

🔹 ServerHello까지는 도달, Java에서만 실패 → IBM JDK의 SSL 정책/구현 차이

CONNECTED(00000003)

depth=0 CN=*.lghnh.com

verify return:1

---

SSL-Session:

Protocol : TLSv1.2

Cipher : ECDHE_RSA_AES_128_GCM_SHA256

📌4. JVM 옵션 점검 (가능성 배제 단계)

✅ 시도한 옵션들

-Djava.net.preferIPv4Stack=true

-Dhttps.protocols=TLSv1.2

-Djdk.tls.client.protocols=TLSv1.2

📌 4-1. -Djava.net.preferIPv4Stack=true

목적

IPv6 / IPv4 충돌 가능성 제거
JVM이 소켓 생성 시 IPv4만 사용하도록 강제
서버가 IPv6 주소를 먼저 잡는데 방화벽 / 네트워크가 IPv6을 막고 있을 때 위함

결과

telnet으로 TCP 연결 정상 → DNS / IP 문제 없음
에러 발생 지점은 SSL Handshake 단계
❌ 이번 이슈와 무관

📌 4-2. -Dhttps.protocols=TLSv1.2, -Djdk.tls.client.protocols=TLSv1.2

* -Dhttps.protocols는 HTTPS 전용 옵션, -Djdk.tls.client.protocols는 JDK JSSE 레벨 옵션으로 적용 범위가 다름.

목적

SSLv3 / TLS1.0 사용 방지 TLSv1.2 사용 강제
JVM이 TLSv1.2가 아닌 프로토콜로 통신을 시도하는지 여부 검증

결과

CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]

JVM은 이미 TLSv1.2로 통신 시도 중
❌ JVM 문제 아님

🚀 4-3. JVM 옵션 점검 결론

가능성	결과
IPv6 충돌	❌ 아님
JVM이 SSLv3로 통신 시도	❌ 아님
TLS 버전 미지정	❌ 아님

👉 JVM 및 애플리케이션 원인 배제 완료

📌 5. SSL 디버그 로그 분석

디버그 옵션 추가

-Djavax.net.debug=ssl,handshake

서버 로그

SSLv3 protocol was requested but was not enabled

IBMJSSE2 will not allow protocol SSLv3

*로컬(Oracle JDK) 로그 (참고용)

java -Djavax.net.debug=ssl,handshake -cp . apiReqSample > ssl_debug.log 2>&1 &

javax.net.ssl|DEBUG|30|main|2025-12-16 09:23:48.933 KST|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key
javax.net.ssl|DEBUG|30|main|2025-12-16 09:23:48.936 KST|ClientHello.java:638|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
//…
})

javax.net.ssl|DEBUG|30|main|2025-12-16 09:23:51.969 KST|ServerHello.java:877|Consuming ServerHello handshake message (
"ServerHello": {
  "server version"      : "TLSv1.2",
  "random"              : "{문자열}",
  "session id"          : "{문자열}",
  "cipher suite"        : "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F)",
  "compression methods" : "00",
  "extensions"          : [
    "renegotiation_info (65,281)": {
      "renegotiated connection": [<no renegotiated connection>]
    },
    "server_name (0)": {
      <empty extension_data field>
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "extended_master_secret (23)": {
      <empty>
    }
  ]
}
)

🚀 결론

API 호출은 IBM JDK(JSSE2) 환경에서 SSL handshake 단계에서 실패하며, 로그상 SSLv3 관련 메시지가 출력되지만 이는 실제 SSLv3 요청이 아니라
IBMJSSE2의 보안 정책에 의해 legacy SSL 특성이 포함된 handshake 흐름이 SSLv3 경로로 판단되어 차단된 동작이다.

동일 요청이 Oracle JDK 환경에서는 TLSv1.2로 정상 처리되는 점에서, 서버 또는 중간 SSL 장비의 legacy SSL 구현과 JDK별 SSL 스택 차이에 따른 호환성 문제로 판단할 수 있다.

=> 이 경우 API 서버 측에서 TLSv1.2 이상으로 통신이 가능하도록 SSL/TLS 설정 수정이 필요하다.

🌟환경 비교

✔ Oracle JDK (로컬)

ClientHello: TLSv1.2
ServerHello: TLSv1.2
legacy SSL 응답이 있어도
→ TLSv1.2 경로로 정상 협상 진행
내부적으로 호환성 처리(fallback/우회)가 허용됨

❌ IBM JDK (개발 서버)

SSL 구현체: IBMJSSE2
legacy SSL 특성이 감지되는 handshake 흐름 발생 시

→ SLv3 관련 경로로 분기

→ 보안 정책상 즉시 차단

❌ fallback / 우회 허용하지 않음

🌟에러 전파 흐름

[API 서버]
   SSL handshake 과정에서 legacy SSL 구현 기반 응답 전달
        ↓
[IBM JDK SSL 엔진 (JSSE2)]
   SSLv3 관련 protocol 경로로 분기 시도
   → 보안 정책상 해당 경로 즉시 차단
        ↓
[JSSE]
   SSL handshake 중단
        ↓
[OS socket layer]
   소켓 초기화 실패 → "invalid parameter" 반환
        ↓
[java.net.SocketException]
        ↓
[Spring ResourceAccessException]

'error' 카테고리의 다른 글

[error] ORA-01461: LONG 값은 LONG 열에 삽입할 때만 바인드할 수 있습니다 (0)	2025.09.01
[error] ORA-06502: PL/SQL: 수치 또는 값 오류: 원시 변수 길이가 너무 깁니다 (For Select & Insert) (0)	2025.08.09
[ajax] Resolved [org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON (0)	2023.09.26
[MyBatis] BindingException@1300 "org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): com.demo.dao.FileMapper.getData" (0)	2023.09.25
whitelabel error page (0)	2023.09.13

현재글java.net.SocketException:A system call received a parameter that is not valid.

메모장